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ABSTRACT 


The  advent  of  personal  computers,  workstations,  and  multiple  interconnected 
Local  Area  Networks  at  the  Naval  Postgraduate  School  (NPS),  Monterey, 
California,  has  resulted  in  significant  distribution,  redundancy,  and  fragmentation 
of  the  data  elements  and  databases  necessary  to  effectively  manage  the 
organization.  This  thesis  addresses  this  issue  by  accomplishing  the  following  two 
goals.  First,  it  develops  a  high-level  model  of  the  organization's  information 
architecture  through  the  use  of  the  Information  Engineering  methodology,  with 
automated  support  from  the  Texas  Instruments'  Integrated  Computer  Aided 
Software  Engineering  (I-CASE)  tool  Information  Engineering  Facility™  (lEF™). 
Based  on  the  high-level  model  it  then  provides  an  analysis  of  data  management 
architecture  alternatives  to  address  the  current  problems.  The  thesis  main 
recommendation  is  for  the  implementation  of  a  client/server  information  processing 
architecture  at  NPS.  The  enterprise  and  information  architecture  analyses  provide 
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I .  THESIS  INTRODUCTION 


A.  PROBLEM  DESCRIPTION 

The  lack  of  effective  data  management  in  a  distributed 
data  environment  exposes  an  organization  to  inconsistent  or 
misleading  information  —  which  in  turn  can  severely  hinder 
decision-making.  The  Naval  Postgraduate  School  (NPS) , 
Monterey,  California,  apparently  suffers  this  problem:  the 
advent  of  personal  computers  (PC) ,  workstations,  and  multiple 
interconnected  Local  Area  Networks  (LAN)  at  NPS  results  in 
significant  distribution,  fragmentation,  and  redundancy  of  the 
data  elements  and  databases  necessary  to  effectively  manage 
the  organization.  In  this  type  of  distributed  data 
environment,  many  organizations  believe  data  should  be  managed 
as  a  strategic  corporate  resource,  and  the  organization  must 
make  critical  decisions  concerning  "...where  to  distribute 
what  data,  who  should  have  access  and  at  what  level,  and  when 
and  how  to  synchronize  that  ...  data."  (Bachman,  1993,  p.  1/4) 

This  thesis  examines  enterprise  data  management  at  NPS  in 
terms  of  its  role  in  Information  Resources  Management  (IRM) . 

B.  BACKGROUND 

Numerous  authors  address  enterprise  data  management  in 
terms  of  the  information  systems  (IS)  department's  role  or 
mission.  Sprague  and  McNurlin  (1993,  pgs.  198-199)  identified 
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four  main  functional  areas  within  this  IS  department's  data 
administration  role:  data  element  standards,  shared  data 
controls,  distributed  data  controls,  and  data  quality 
controls . 

Data  element  standards  are  required  to  eliminate  data 
redundancies  and  data  definition  inconsistencies,  thus 
ensuring  data  and  information  compatibility  throughout  the 
organization.  Establishment  and  use  of  standard  data  elements 
and  data  definitions  in  an  organization-wide  data  dictionary 
is  not  in  itself  sufficient  to  fulfill  the  requirements  of 
this  functional  area.  Some  policy  implementation  mechanism 
must  be  put  into  place  to  maintain  the  data  integrity,  and  all 
the  users  must  be  trained  in  the  proper  use  of  data 
definitions . 

Shared  data  can  be  defined  as  the  data  that  is  used  by  two 
or  more  organizational  units  within  the  enterprise.  However, 
full  data  administration  requires  treating  all  data  throughout 
the  enterprise  as  shared  data,  whether  or  not  it  is  used  by 
more  than  one  organizational  unit.  This  type  of  total  data 
control  is  essential  to  ensure  that  cross-departmental 
application  programs  use  interoperable  data,  now  and  in  the 
future . 

Distributed  data  can  be  defined  as  the  data  that  is  used 
by  organizational  units  which  is  physically  dispersed,  ie., 
situated  in  more  than  one  location.  The  use  of  distributed 
data  resources  significantly  complicates  data  administration. 
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and  requires  a  greater  degree  of  standard  operating  procedures 
and  practices  to  ensure  full  data  integration  and 
interoperability. 

Data  quality  mast  be  maintained  through  the  implementation 
and  enforcement  of  specific  policies  and  procedures.  One 
favored  approach  is  the  method  currently  in  use  at  NPS,  which 
is  require  the  owners  of  the  data  to  be  responsible  for  the 
data's  accuracy;  however,  the  determination  of  proper  data 
ownership  is  a  frequent  stumbling  block  with  this  approach. 

The  data-oriented  view  of  the  mission  of  an  IS 
organization  is  also  shared  by  Steven  Spewak  and  Steven  Hill 
(1993,  p.  5)  who  claim  the  IS  department's  mission  should  be 
"providing  quality  data  to  those  who  need  it".  Spewak  and 
Hill  went  on  to  adapt  Deming's  14  Points  for  Quality  (Spewak 
and  Hill,  1993,  p.  5)  and  created  a  parallel  interpretation, 
which  they  titled  "14  Points  to  Data  Quality".  Figure  I.l 
presents  some  of  these  points. 

Commercial  sector  business  enterprises  are  not  the  only 
organizations  interested  in  strategic  data  management.  The 
Federal  Government,  the  Department  of  Defense  (DoD) ,  the 
Department  of  the  Navy  (DoN) ,  and  even  NPS  also  recognize  the 
importance  of  data  management.  Chapter  II  provides  an 
overview  of  numerous  standards,  rules,  regulations,  and 
guidance  developed  by  the  Federal  Government,  the  DoD,  the 
DoN,  and  NPS  that  are  applicable  to  Information  Resources 
Management  (IRM)  and  data  management  at  NPS. 
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Extract  from  "14  Points  to  Data  Quality” 

Develop  a  charter  for  Data  Resource  Management  (DRM). 

Manage  data  as  an  asset;  commit  to  shared  data  and  data  integrity. 

Develop  measures  for  quality  data. 

Establish  a  data-driven  migration  strategy  based  on  data  creation  (source 
data  systems). 

Understand  your  business  (functional  business  model,  business  plans); 
correct  data  errors  and  eliminate  the  causes  of  bugs  with  better 
methodologies. 

Institute  DRM  training  programs. 

Develop  standards  and  enforcement  mechanisms  to  ensure  data  quality. 

Comply  with  standards  through  leadership  and  responsibility  for  data  quality 
(provide  compliance  incentives). 

Management  must  commit  to  these  data  quality  principles  (establish  DRM, 
reorganize,  authorize). 

Figure  I.l  Extract  from  "14  Points  for  Data  Quality" 

(Spewak  and  Hill,  1993,  p.  5) 

Data  management  or  data  administration  is  just  one  part  of 
what  is  commonly  known  as  Infontiation  Resources  Management. 
Many  different  definitions  for  IRM  exist;  Ward,  Griffiths,  and 
Whitmore  (1990,  p.  338)  state  that  IRM  consists  of  four 
P^irtiary  activities :  data  administration,  data  dictionary 
administration,  database  administration,  and  provision  of 
access  services.  Figure  1.2  presents  this  view  of  the  IRM 
activities,  and  Figure  1.3  provides  a  listing  of  the  tasks 
commonly  associated  with  each  IRM  activity. 
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Figure  1.2  Information  Resources  Management  (IRM)  Activities 
(Ward,  Griffiths,  Whitmore,  1990,  p.  339) 


Slight  modification  of  the  results  of  a  Boeing  Company 
long-range  vision  study  (Sprague  and  McNurlin,  1993,  p.  50) 
provides  the  architecture  pyramid  shown  in  Figure  1.4. 

The  business  process  architecture  layer  defines  the 
organization's  business  activities,  functions,  and  processes . 


INFORMATION  RESOURCES  MANAGEMENT  AGTIVITy  TASKS 


Data  Admkiistration 


1.  Data  planning  (shown  as  a  separate  activity  in  Figure  1.2) 

2v  Identification  of  infonaation  needs 

and  procedures 

4.  Management  of  corporate  data  models 

5.  Coordination  for data-related  problem  resolution 

6.  Interfeco  with  the  business 

:  7,  Establishment:  and  implementation  of  activity  and  data  analysis 

B.iEstablishment  of  controls  and  procedures  for  data  security  and  recoveryiprivacyi  and  integrity 

Data  Dictjonaty  Administration 


f.  Authoritatiye  source  of  infonnation  -  the  glossary  and  dictionary  of  the  business 
2;;  .Evaluation  and  selection  of  data  dictionary  management  software 
:3;  ;Coordtnation  of  the  data  dictionary  contents  and  meta-modeis 

4.  ::Establishment  of  standards  and  procedures  for  use  of  the  data  dicbonaty 

5.  Data  definition  and  impact  analysis 


Database  Administration 


1.  Design,  development,  implementation  and  operation  of  the  organization's  databases 

2.  Establishment  of  technical  standards  and  procedures  for  database  activities 

3. ::  Eva(uation  and  selection  of  database  management  software 

4.  Database  environment  and  services  monitoring  and  control 
Database  housekeeping  tasks —  bacirups,  archiving,  recovery,  restart 

^.  Roltcy  ooordinafa'on  with  data  administration  and  data  dictionary  administration 
7;  Systems  development  planning  coordination  for  effective  database  use 


Information  Access  Services 


1i  :Policies  and  procedures  regarding  ownership,  responsibility,  security,  and  access  rights 
2^  Information  access  tools  and  techniques 
User  education  to  promote  benefits  of  information  management 
4.  Data  quality,  availability,  and  accessibfiity 


Figure  1.3  Information  Resources  Management  Tasks 
(Ward,  Griffiths,  and  Whitmore 


1990 


James  Brancheau  (1989,  p.  9)  provides  an  excellent  definition 
for  the  information  architecture  layer,  along  with  a  concise 
description  of  how  an  information  architecture  is  used  within 
an  organization  to  support  the  business  process  architecture 
layer: 
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An  information  architecture  is  a  high-level  map  of  the 
information  requirements  of  an  organization.  It  is  a 
personnel,  organization  and  technology  independent  profile 
of  the ^  major  information  categories  used  within  an 
enterprise.  It  provides  a  way  to  map  the  information 
needs  of  an  organization,  relate  them  to  specific  business 
functions,  and  document  their  interrelationships.  The 
interrelationships  between  information  and  functions  are 
used  to  guide  applications  development  and  facilitate 
integration  and  sharing  of  data.  An  information 
architecture  provides  a  proactive  basis  for  information 
systems  development  as  opposed  to  the  reactive  backlog 
approach  common  in  many  organizations. 

A  data  management  architecture  layer  supports  the  information 

architecture  layer,  and  consists  of  all  the  policies, 

procedures,  and  methodologies  used  for  data  management. 

Finally,  the  technical  infrastructure  architecture  layer, 

which  underlies  and  supports  the  data  architecture,  consists 

of  the  organization's  hardware,  software,  and  communications 

networks . 

This  discussion  of  the  architecture  pyramid  leads  to  the 
two-fold  purpose  of  this  thesis  research:  first,  investigate 
the  existing  information  architecture  and  data  management 
architecture  at  NFS;  and  second,  determine  a  recommended  data 
management  architecture  to  meet  NFS  information  management 
requirements,  subject  to  resource  constraints. 


C .  RESEARCH  QUESTIONS 

The  primary  research  questions  to  be  answered  by  this 
thesis  thus  become: 

1.  What  is  the  information  architecture  of  the  NFS 
enterprise? 
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2.  What  is  the  most  appropriate  data  management  architecture 
for  the  NPS  enterprise  data,  considering  local 
constraints  on  both  financial  and  personnel  resources? 

The  primary  research  questions  will  be  answered  by  answering 

a  set  of  subsidiary  research  questions.  The  subsidiary 

research  questions  are: 

Information  Architecture 

1.  What  are  the  business  activities  or  functions  of  the  NPS 
enterprise? 

2-  What  are  the  information  needs  of  the  NPS  enterprise? 

3.  How  are  the  information  needs  related  to  the  business 
functions? 

Data  Management  Architecture 

4 .  What  are  the  potential  data  management  architecture 
alternatives  for  the  NPS  enterprise  data? 

5.  What  are  the  financial  and  personnel  resource 
constraints? 

6.  What  is  the  recommended  data  management  alternative  for 
the  NPS  enterprise  data,  considering  all  resource 
constraints? 

D .  INVESTIGATIVE  METHODOLOGY 

The  investigative  approach  consists  of  efforts  in  four 
broad  areas:  collection  of  background  information  for  use  in 
the  analysis  of  the  NPS  information  and  data  management 
architectures;  the  analysis  of  the  NPS  enterprise,  its 
information  architecture,  and  its  data  management 
architecture;  collection  of  information  for  use  in  the 
analysis  of  the  data  management  architecture  alternatives;  and 
the  analysis  of  these  data  management  alternatives. 
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A  brief  description  of  each  research  area's  investigative 
methodology  follows: 

1 .  NPS  Infonnation  and  Data  Architectures  Data  Collection 

The  data  collection  approach  consists  of  the 
identification  and  review  of  niimerous  organizational 
documents,  the  development  and  distribution  of  survey 
questionnaires  to  information  system  users,  and  the  conduct  of 
interviews  with  upper  level  management  personnel,  middle  level 
management  personnel,  information  system  technical  personnel, 
and  information  system  users  at  multiple  levels  of  management. 

2 .  Analysis  of  NPS  Enterprise  and  Architectures 

The  NPS  enterprise  analysis  consists  of  performance  of 
the  tasks  outlined  in  the  Information  Strategy  Planning  and 
Business  Area  Analysis  stages  of  the  information  engineering 
software  development  methodology  (Martin,  1990a) .  The 
analysis  develops  and  discusses  an  NPS  enterprise  model  using 
the  automated  support  provided  by  a  Computer-Aided  Software 
Engineering  (CASE)  tool  —  Texas  Instruments'  (TI)  Information 
Engineering  Facility™  (lEF™)  . 

3 .  Data  Management  Architecture  Alternatives  Data 

Collection 

The  data  collection  consists  of  a  general  literature 
review  of  data  management  architecture  alternatives,  followed 
by  specific  research  into  the  publications  and  vendor 
literature  for  several  representative  systems,  applications, 
and  products.  Additional  data  collection  efforts  include 
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attendance  at  numerous  industry  trade  shows  and  exhibitions, 
which  provide  opportunities  to  examine  representative  systems, 
applications  and  products,  and  discuss  technology  issues  with 
vendor  representatives.  Attendance  at  numerous  vendor- 
sponsored  product  seminars  supplement  trade  show  attendance 
data  collection  efforts,  and  provide  more  detailed  information 
about  specific  technologies,  technology  implementation,  and 
available  commercial  products. 

4.  Analysis  of  Data  Management  Architecture  Alternatives 
The  data  management  architecture  alternatives  analysis 
consists  of  the  application  of  guidance  and  procedures  derived 
from  the  Federal  Information  Resources  Management  Regulations 
(FIRMR)  (41  CFR  201)  and  other  Federal  Government  agency 
publications.  Subjective  evaluation  of  each  data  management 
alternative  with  respect  to  the  elements  of  the  analysis 
criteria,  albeit  at  an  overview  level,  along  with  the 
application  of  financial  and  personnel  resource  constraints, 
allows  selection  and  recommendation  of  a  data  management 
architecture  alternative  for  implementation  within  the  NFS 
enterprise . 

E.  SCOPE  AND  LIMITATIONS  OF  THE  THESIS  RESEARCH 

Development  of  an  information  architecture  for  an  entire 
organization  is  a  complex  and  difficult  task  due  to  the  broad 
scope  of  the  project.  Analysis  of  an  organization  as  large 
and  unique  as  NFS  requires  many  more  man-hours  than  can  be 
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devoted  to  the  subject  within  the  limited  timeframe  allotted 
to  a  student  at  NPS  for  thesis  research.  Therefore,  this 
thesis  does  not  attempt  to  provide  a  complete  and 
comprehensive  analysis  of  the  NPS  information  architecture. 
This  research  follows  the  outlined  tasks  within  the  first  two 
of  seven  stages  of  the  information  engineering  methodology 
(described  in  Chapter  III)  to  provide  a  broad,  high-level 
overview  of  the  information  architecture  at  NPS.  The 
information  architecture  overview  consists  of  identification 
and  definition  of  the  top-level  business  functions, 
identification  and  definition  of  the  information  subject  areas 
and  corresponding  top-level  data  entity  types,  and  a  high- 
level  definition  of  some  of  the  relationships  between  the 
business  functions  and  the  data  entity  types.  The  overview 
analysis  provides  sufficient  depth  to  make  a  preliminary 
assessment  of  the  NPS  organization,  and  provide  comments  and 
recommendations  for  changes  to  the  NPS  organizational 
structure.  Chapter  IV  discusses  several  additional 
limitations  of  the  analysis  that  occur  as  a  result  of  the  use 
of  lEF™. 

Proper  evaluation  and  selection  of  a  specific  data 
management  architecture  is  likewise  a  daunting  endeavor,  since 
the  analysis  must  not  only  include  the  data  architecture,  but 
also  the  underlying  technical  infrastructure  issues. 
Additionally,  a  true  evaluation  and  selection  process  includes 
evaluation  of  vendor-specific  implementations  of  the  various 
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data  management  architectures,  not  just  a  generic  data 
management  architecture  concept.  This  thesis  does  not  attempt 
to  evaluate  vendor-specific  implementations;  the  analysis  only 
discusses  the  various  generic  alternative  concepts  in  broad 
and  general  terms.  The  description  of  the  alternative  data 
management  architecture  concepts  and  the  analysis  of  the  NPS 
enterprise  information  architecture  provide  sufficient 
information  to  allow  a  recommendation  for  a  data  management 
architecture  for  the  NPS  enterprise. 

F.  STRUCTURE  OF  THE  THESIS 

Chapter  II  provides  an  overview  of  numerous  standards, 
rules,  regulations,  and  guidance  developed  by  the  Federal 
Government,  the  Department  of  Defense  (DoD) ,  the  Department  of 
the  Navy  (DoN)  ,  and  NPS  that  are  applicable  to  Information 
Resources  Management  (IRM)  and  data  management  at  NPS. 

Chapter  III  provides  a  description  and  discussion  of 
various  system  analysis  methodologies,  including  the 
information  engineering  methodology  used  for  the  NPS 
enterprise  analysis,  followed  by  a  description  of  some  of  the 
features  of  TI's  CASE  tool  lEF™. 

Chapter  IV  provides  a  broad,  high-level  overview  analysis 
of  the  NPS  enterprise  using  the  Information  Strategy  Planning 
(ISP)  and  Business  Area  Analysis  (BAA)  phases  of  the 
information  engineering  methodology.  The  results  of  the 
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analysis  provide  the  basis  for  several  recommendations  for 
changes  to  the  NPS  organizational  structure.  The  chapter  also 
provides  a  brief  discussion  of  the  financial  and  personnel 
resource  constraints  related  to  IS  at  NPS. 

Chapter  V  provides  a  general  discussion  of  the  data 
management  architecture  alternative  technologies  available  in 
industry  today. 

Chapter  VI  provides  a  discussion  and  analysis  of  the  NPS 
information  architecture-driven  requirements,  and  an  analysis 
of  the  alternative  data  management  architecture  concepts. 

Chapter  VII  provides  a  discussion  of  the  recommended  data 
management  architecture  alternative  subject  to  all  resource 
constraints,  a  summary  of  other  recommendations  as  a  result  of 
the  study,  an  evaluation  of  the  information  engineering 
methodology  and  of  the  TI  CASE  tool  lEF™,  and  recommendations 
for  further  study. 

Appendices  A  through  F  provide  background  information 
which  supports  the  discussions  in  each  chapter.  Appendix  A 
provides  a  listing  of  available  documents  which  provide  IRM 
guidance.  Appendix  B  provides  a  listing  of  some  of  the 
Federal  Information  Processing  Standards  (FIPS)  applicable  to 
IRM.  Appendix  C  provides  a  description  of  the  lEF™  Toolsets. 
Appendix  D  provides  the  NPS  enterprise  analysis  lEF™ 
printouts,  and  has  a  separate  and  limited  distribution  due  to 
its  bulk.  Appendix  E  provides  a  discussion  of  middleware 
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technology.  Appendix  F  provides  a  discussion  of  the  FIRMR 
guidance  for  analysis  of  requirements  and  alternatives. 
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II.  INFORMATION  RESOURCES  MANAGEMENT  GUIDELINES 

This  chapter  provides  an  overview  of  the  standards,  rules, 
regulations,  and  other  policy  guidance  developed  by  the 
Federal  Government,  the  Department  of  Defense  (DoD)  ,  the 
Department  of  the  Navy  (DoN) ,  and  the  Naval  Postgraduate 
School  (NPS)  that  are  applicable  to  Information  Resources 
Management  (IRM)  at  NPS.  The  key  directives  at  each  level  are 
examined  and  discussed.  The  emphasis  in  the  discussion  is  on 
the  management  of  information  or  data;  directives  addressing 
other  IRM  topics  are  not  covered. 

A.  FEDERAL  RULES,  REGULATIONS,  STANDARDS,  AND  GUIDANCE 

The  Federal  Government's  IRM  policy  guidance  is 
distributed  throughout  many  documents.  The  principal  IRM 
policies  are  provided  in  the  Federal  Information  Resources 
Management  Regulations  (FIRMR)  and  the  Office  of  Management 
and  Budget  s  (0MB)  Circular  A— 130.  Additional  non-mandatory 
guidance  and  direction  is  available  from  many  other  Federal 
agencies,  including  the  Office  of  Technical  Assistance  within 
the  Information  Resources  Management  Service  (IRMS)  of  the 
U.S.  General  Services  Administration  (GSA) .  Another  source  of 
regulatory  information  is  the  Federal  Information  Processing 
Standards  (FIPS) .  These  documents  are  discussed  in  some 
detail  in  the  following  sections. 
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1.  Federal  Information  Resources  Management  Regulations 

(FIRMR)  -  41  CFR  CH.  201 

The  FIRMR  "...applies  to  the  creation,  maintenance, 
and  use  of  Federal  information  processing  (FIR)  resources  by 
Federal  agencies."  (41  CFR  201-1.000)  Specifically,  the  FIRMR 
"...is  established  to  publish  and  codify  uniform  policies  and 
procedures  pertaining  to  information  resources  management 
activities  by  Federal  agencies."  (41  CFR  201-3.101)  These 
policies  cross  a  wide  spectrum  of  responsibilities,  including 
management  and  use  of  information  and  records,  management  and 
use  of  information  processing  resources,  and  the  acquisition 
of  information  processing  resources.  The  policies  are  broad 
and  general  in  nature,  and  are  aimed  at  providing  guidance  at 
a  Federal  agency  level.  However,  the  policies  also  apply  to 
specific  organizations  within  each  Federal  agency,  such  as  the 
Naval  Postgraduate  School.  One  way  the  FIRMR  policies  can  be 
easily  interpreted  and  applied  to  a  specific  organization  is 
by  simply  replacing  the  word  "agency"  with  the  word 
"organization"  throughout  the  FIRMR' s  subchapters. 

The  first  subchapter  provides  general  information 
about  the  FIRMR  and  its  structure.  One  useful  feature  of  this 
subchapter  is  a  glossary  of  terms,  definitions  and  acronyms. 

The  second  subchapter.  Subchapter  B  —  Management  and 
Use  of  Information  and  Records,  contains  policies  "...designed 
to  promote  the  economic  and  efficient  management  and  use  of 
information..."  (41  CFR  201-6.002).  This  subchapter  focuses 
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on  two  major  items:  an  overview  of  the  importance  of 
information  management;  and  policies  for  strategic  planning, 
records  management,  and  use  of  the  GSA's  IRM  review  and 
evaluation  programs. 

The  importance  of  managing  information  as  a  strategic 
organizational  asset  throughout  its  life  cycle  is  one  of  the 
key  considerations  emphasized  in  Subchapter  B.  One  example  of 
a  Federal  agency-level  policy  that  is  equally  applicable  to 
individual  organizations  within  the  agency  is  the  FIRMR's 
direction  to  conduct  strategic  planning: 

Federal  agencies  shall  establish  strategic  planning 
processes  to: 

Plan^  for  the  creation,  collection,  processing, 
transmission,  use,  storage,  dissemination,  and  disposition 
of  information; 

Ensure  that  program  officials  and  information  resources 
management  officials  (including  records  managers) 
participate  in  the  development  and  annual  revision  of  a  5- 
year  plan  for  meeting  the  agency"s  information  technology 
needs;  and 

Ensure  that  the  agency's  information  needs  are 
determined  before  conducting  a  requirements  analysis  for 
FIP  resources.  (41  CFR  201-7.002) 

The  Computer  and  Information  Services  Directorate  (Code  05)  at 

NPS  coordinates  the  development  and  annual  review  of  a  five- 

year  information  technology  plan  which  addresses  these  issues. 

The  determination  of  the  NPS  organization's  needs  is  a  key 

part  of  the  author's  research  to  determine  an  enterprise-wide 

information  architecture.  Subchapter  B  of  the  FIRMR  follows 

up  the  discussion  of  the  planning  policy  with  a  listing  of 
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specific  factors  to  consider  when  planning  future  needs. 
These  factors  include:  the  identification  of  mission- 

essential  records  and  information;  and  determination  of 
information  format,  medium,  quantity,  integrity,  and 
timeliness  requirements. 

Two  more  records  management  issues  addressed  in  this 

subchapter  are  ensuring  that  an  organization's  records  can  be 

accessed  quickly  and  reliably,  and  controlling  the  creation 

and  use  of  forms  and  reports.  The  following  extracts  of 

specific  FIRMR  procedures  apply  not  only  to  records  management 

but  also  to  information  management  (41  CFR  201-9.103): 

Control  the  creation,  maintenance,  and  use  of  agency 
records  and  the  collection  and  dissemination  of 
information  to  ensure  that  the  agency: 

Does  not  accumulate  unnecessary  records; 

Does  not  create  forms  and  reports  that  collect 
information  inefficiently  or  unnecessarily; 

Periodically  reviews  all  existing  forms  and  reports 
(both  those  originated  by  the  agency  and  those  responded 
to  by  the  agency  but  originated  by  another  agency  or 
branch  of  Government)  to  determine  if  they  need  to  be 
improved  or  cancelled; 

Maintains  its  records  cost  effectively  and  in  a  manner 
that  allows  them  to  be  retrieved  quickly  and  reliably; 

Additionally,  each  agency  should  strive  to: 

Provide  agency  personnel  with  the  information  needed  in 
the  right  place,  at  the  right  time,  and  in  a  useful 
format; 

Eliminate  unnecessary  reports  and  design  necessary 
reports  for  ease  of  use; 
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Organize  agency  files  (i)  so  that  needed  records  can  be 
found  rapidly  (ii)  to  ensure  that  records  are  complete  and 
(iii)  to  facilitate  the  identification  and  retention  of 
permanent  records  and  the  prompt  disposal  of  temporary 
records.  (41  CFR  201-9.103) 

Interpretation  of  these  statements  yields  support  for  the 
central  administration  and  management  of  an  organization's 
data,  in  line  with  the  strategic  resource  view  of  information. 
These  statements  also  place  an  emphasis  on  organization-wide 
data  integration  and  information  system  interoperability  in 
order  to  more  effectively  and  efficiently  manage  the 
information. 

Subchapter  C,  Management  and  Use  of  Federal 
Information  Processing  (FIP)  Resources,  prescribes  policies 
for  the  planning  and  budgeting,  acquisition,  operation,  review 
and  evaluation,  and  disposition  of  FIP  resources;  the 
subchapter  also  lists  GSA's  available  services  and  assistance. 
The  planning  and  budgeting  guidance  supports  the  policies  in 
Subchapter  B  and  is  directed  at  Federal  agencies  at  the  agency 
level.  The  acquisition  policies  provide  specific  guidance  for 
analyzing  information  needs,  requirements,  and  alternatives, 
and  addresses  the  use  of  standards.  It  is  important  to  note 
that  the  acquisition  section's  discussion  of  standards  only 
provides  overall  guidance  to  use  FIPS  and  other  standards; 
each  standard  must  be  individually  reviewed  to  determine  its 
applicability  for  any  given  requirement.  The  operations 
policies  discuss  the  requirements  to  maintain  FIP  resource 
inventories,  provide  for  security  and  information  privacy,  and 
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share  excess  FIP  resources.  The  review  and  evaluation 
discussion  provides  details  of  two  IRM  programs:  The  Federal 
Information  Resources  Management  Review  Program,  administered 
by  each  individual  agency;  and  the  Information  Resources 
Procurement  and  Management  Review  Program,  administered  by 
GSA.  The  disposition  policies  provide  guidance  for  disposing 
excess  or  obsolete  FIP  resources. 

2.  Office  of  Management  and  Budget  (0MB)  Circular  A-130 
Circular  No.  A-130  implements  the  IRM  policies 
required  by  the  Paperwork  Reduction  Act  of  1980,  44  U.S.C. 
Chapter  35  (0MB,  1993) .  The  Paperwork  Reduction  Act  includes 
one  key  goal  of  interest  with  respect  to  information 
management:  "Coordinate,  integrate,  and  where  practical,  make 
uniform.  Federal  information  policies  and  practices"  (41  CFR 
201-6.001) .  Circular  A-130,  like  the  FIRMR,  provides  policies 
which  are  broad  and  general  in  nature,  and  are  aimed  at 
providing  guidance  at  a  Federal  agency  level.  However,  the 
policies  specifically  apply  to  organizations  within  each 
Federal  agency  as  well,  due  to  the  Circular's  requirement  to: 

Ensure  that  the  information  policies,  principles, 
standards,  guidelines,  rules,  and  regulations  prescribed 
by  0MB  are  implemented  appropriately  within  the  agency. 
(0MB,  1993,  p.  11) 

The  Circular  A-130  sections  most  applicable  to  a  discussion  of 
information  management  are  the  Definitions  section  and  the 
Policy  section.  The  section  on  definitions  is  similar  to  the 
FIRMR' s  glossary  of  terms,  providing  definitions  for  the  key 
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terms  used  throughout  the  document.  The  policy  section  is 
divided  into  two  areas:  Information  Management  Policy  and 
Information  Systems  and  Information  Technology  Management 
Policy. 


The  Information  Management  Policy  area  includes  nine 
topics :  information  management  planning,  information 
collection,  electronic  information  collection,  records 
management,  providing  information  to  the  public,  information 
dissemination  management  system,  avoiding  improperly 
restrictive  practices,  electronic  information  dissemination, 
and  safeguards.  Excerpts  from  the  planning  policies  identify 
several  actions  that  must  be  carried  out  by  agencies,  and 
organizations  within  those  agencies,  including: 

Seek  to  satisfy  new  information  needs  through 
interagency  or  intergovernmental  sharing  of  information, 
or  through  commercial  sources,  where  appropriate,  before 
creating  or  collecting  new  information; 

Integrate  planning  for  information  systems  with  plans 
for  resource  allocation  and  use,  including  budgeting, 
acquisition,  and  use  of  information  technology; 

Train  personnel  in  skills  appropriate  to  management  of 
information; 

Use  voluntary  standards  and  Federal  Information 
Processing  Standards  where  appropriate  or  required; (0MB, 
1993,  p.  6) 


These  directed  actions  are  a  driving  force  for  the 
standardization  of  data  to  support  the  sharing  of  information. 
They  also  point  out  the  importance  of  information  as  a 
strategic  resource,  and  the  emphasis  that  must  be  placed  on 
proper  information  management. 
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One  policy  in  the  area  of  records  management  stands 
out:  "ensure  the  ability  to  access  records  regardless  of  form 
or  medium".  (0MB,  1993,  p.  7)  This  policy  can  be  interpreted 
many  ways;  one  interpretation  provides  support  for  the 
standardization  of  the  records,  and  the  data  contained  within 
each  record. 

Two  of  the  policies  discussed  under  the  safeguards 
section  are  likewise  worthy  of  note,  since  they  affect  the 
type  of  information  which  can  be  maintained  within 
organizational  databases: 

Limit  the  collection  of  information  which  identifies 
individuals  to  that  which  is  legally  authorized  and 
necessary  for  the  proper  performance  of  agency  functions; 

Limit  the  sharing  of  information  that  identifies 
individuals  or  contains  proprietary  information  to  that 
which  is  legally  authorized,  and  impose  appropriate 
conditions  on  use  where  a  continuing  obligation  to  ensure 
the  confidentiality  of  the  information  exists;  (0MB,  1993, 

p.  10) 

These  policies  are  further  elaborated  in  Appendix  I  to  the 
Circular,  which  is  devoted  entirely  to  each  Federal  agency's 
responsibilities  for  implementing  the  reporting  and 
publication  requirements  of  the  Privacy  Act  of  1974,  5  U.S.C. 
552a,  as  amended  (0MB,  1993,  p.  17) . 

The  Information  Systems  and  Information  Technology 
Management  Policy  area  prescribes  18  specific  agency 
requirements  related  to  an  information  system's  life  cycle 
(0MB,  1985,  p.  52736) .  Some  of  these  actions  include: 
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1.  a  requirement  for  multi-year  strategic  planning; 

2.  periodic  review  of  system  requirements  over  the  system 
lifecycle  for  applicability; 

3.  non-duplication  of  information  systems  available  from 
other  agencies; 

4.  use  of  commercial-off-the-shelf  (COTS)  software  when  cost 
effective;  and 

5.  use  of  FIPS  and  other  standards  unless  costs  exceed 
benefits  or  use  prevents  mission  accomplishment. 

These  requirements  do  not  provide  additional  guidance;  they 

simply  support  the  policies  addressed  in  earlier  sections  of 

the  document. 

The  remaining  sections  of  the  0MB  Circular  provide 
guidance  in  other  areas  related  to  information  system 
management.  Appendix  II  to  Circular  A-130  provides  guidance 
on  cost  accounting  issues  and  interagency  sharing  of  IS 
facilities.  Appendix  III  addresses  security  issues  relating 
to  Federal  automated  information  systems.  Appendix  IV 
provides  an  analysis  of  the  key  sections  of  the  Circular  to 
provide  some  explanations  for  the  Circular's  content.  (0MB, 
1985,  p.  52741-52744) 

3.  GSA  Information  Resource  Management  Service  (IRMS) 

Publications 

The  IRMS's  Office  of  Technical  Assistance  (OTA) 
disseminates  a  wealth  of  useful  information  through  the 
publication  of  numerous  information  technology  documents. 
The  IRMS-OTA  documents  do  not  constitute  official  Federal 
Government  or  GSA  policy  or  regulation;  they  only  provide 
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ideas  and  information,  and  can  serve  as  useful  references  for 
IS  managers.  Some  of  these  documents  are  available  free  of 
charge  to  Government  agencies;  others  can  be  purchased  for  a 
nominal  fee  from  the  National  Technical  Information  Service 
(NTIS)  of  the  Department  of  Commerce. 

Similarly,  the  IRMS’s  Federal  Systems  Integration  and 
Management  Center  (FEDSIM)  routinely  publishes  documents  which 
shares  the  information  gained  by  FEDSIM  in  its  work  with  other 
Federal  agencies.  These  publications  are  also  offered  free  of 
charge  to  Government  organizations.  One  example  of  this  type 
of  document  is  the  Information  Resources  Management  Strategic 
Planning  Guide  (FEDSIM,  1993),  which  provides  a  guideline  for 
compliance  with  the  FIRMR's  and  0MB  Circular  A-130's 
requirements  to  conduct  strategic  IRM  planning  within  Federal 
agencies . 

A  listing  (titles  and  description)  of  some  of  the 
dociaments  available  from  the  IRMS  is  included  in  Appendix  A. 

4.  Federal  Information  Processing  Standards  (FIPS) 

FIPS  are  individual  standards  related  to  automated 
data  processing,  and  are  categorized  in  one  of  five  areas: 
hardware,  software,  application,  data,  and  operations.  Each 
category  also  has  sub-categories,  and  some  FIPS  fall  within 
more  than  one  category,  such  as  FIPS  dealing  with  network 
protocols.  The  first  FIPS  were  issued  in  the  late  1960s  by 
the  U.S.  Department  of  Commerce's  National  Bureau  of 
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Standards,  now  known  as  the  National  Institute  of  Standards 
and  Technology  (NIST) .  The  majority  of  the  technical  FIPS 
adopt  American  National  Standards  (ANS)  for  automated  data 
processing  developed  by  the  American  National  Standards 
Institute's  (ANSI)  X3  Committee  (Computers  and  Information 
Processing) .  Some  adopt  International  Standards  approved  by 
the  International  Standards  Organization  (ISO) ,  or  joint 
ISO/ANSI  standards.  Many  FIPS  are  simply  non-mandatory 
guidelines  written  to  serve  as  technical  references  for  IS 
personnel  in  some  area  of  information  processing.  Some  of 
these  standards  have  been  adopted  and  implemented  commercially 
as  well.  The  Federal  Standards  are  periodically  reviewed,  and 
the  FIPS  are  revised  or  superseded  if  required  whenever  the 
underlying  ISO  or  ANSI  standards  are  updated. 

The  FIPS  are  too  numerous  to  attempt  to  list  and 
describe  in  their  entirety.  Even  listing  just  the  FIPS  that 
can  be  considered  applicable  to  information  processing  or 
information  management  at  NPS  would  be  excessive;  therefore, 
a  small  representative  sampling  of  the  applicable  FIPS  in  each 
category  is  provided  in  Appendix  B.^ 


^^NIST  publishes  a  handbook,  updated  annually,  which 
provides  an  index  and  description  of  all  the  Federal 
Standards . 
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B.  DEPARTMENT  OF  DEFENSE  (DoD)  RULES,  REGULATIONS,  STANDARDS, 

AND  GUIDANCE 

DoD  guidance  tends  to  fall  into  one  of  three  categories: 
implementation  of  higher-level  guidance,  such  as  the  FIRMR  and 
0MB  Circular  A-130,  with  DoD  specific  supplementation; 
specific  DoD  IS  acquisition  and  life-cycle  management 
guidance;  and  the  Corporate  Information  Management  (CIM) 
Initiatives.  The  implementation  of  higher-level  guidance  is 
generally  provided  as  policy  in  DoD  Directives,  supported  by 
procedures  in  DoD  Instructions-  The  DoD  IS  acquisition 
policies  and  procedures  are  likewise  promulgated  through 
specific  DoD  Directives  and  Instructions.  Many  of  the 
directives  associated  with  information  management  are  recent 
revisions  brought  about  by  the  implementation  of  the  CIM 
Initiative;  other  directives  are  still  under  revision. 

1 .  The  Corporate  Information  Management  (CIM)  Initiatives 
The  Goldwater-Nichols  Act  of  1979  directed  government 
organizations  to  streamline  their  organizational  structures. 
As  new  information  processing  technologies  became  available, 
DoD’s  focus  shifted  to  information  management,  resulting  in 
the  CIM  Initiatives.  The  CIM  Initiatives  mandated  that 

organizations  must,  prior  to  automating  any  process, 
scrutinize  their  work  processes,  delete  unnecessary  processes, 
and  eliminate  redundancy;  in  other  words,  organizations  must 
conduct  business  process  engineering.  The  key  focus  of  the 
DoD  directives  produced  as  a  result  of  the  CIM  Initiatives  is 
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the  integration  of  common  business  functions  across 
organizational  lines.  (ODDI,  1993) 

The  Corporate  Information  Management  For  the  21st 
Century  -  a  DoD  Strategic  Plan  (ASD-C3I,  1994)  contains  the 
current  top-level  guidance  for  all  information  management 
activities  within  the  DoD.  The  plan  includes  goals  in  the 
following  six  areas:  functional  process  reengineering,  the 
standardization  and  sharing  of  data,  the  migration  of 
information  systems,  a  computer  and  communications 
infrastructure,  and  management  of  the  Corporate  Information 
Management  (CIM)  initiative  throughout  DoD.  The  goal  related 
to  standardization  and  sharing  of  data  is  the  most  relevant  to 
the  research  for  this  thesis.  The  specific  objectives  for 
this  goal  (ASD-C3I,  1994,  p.  9)  are: 

Derive  standard  definitions  of  data,  on  an  aggressive 
schedule . 

Establish  strong  management  of  data  quality,  including 
data  availability,  integrity,  accuracy,  and  security. 

The  DoD  plan  to  meet  these  objectives  (ASD-C3I,  1994,  p.  9) 

includes : 

1.  Establish  policies  and  programs  to  ensure  that 
requirements  for  end-to-end  data  availability, 
integrity/quality,  and  security  are  met. 

2.  Establish  programs  to  ensure  compliance  with  data 
policies  and  programs. 

3.  Develop  standard  definitions  of  data  through  the 
application  of  a  DoD  data  model  and  functional  data 
models,  utilizing  a  central  data  dictionary. 
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4.  Aggressively  pursue  opportunities  to  share  data  and 
establish  shared  data  bases  within  the  DoD,  with  other 
government  agencies,  and  with  allies. 

5.  Coordinate  and  integrate  DoD-wide  data  standardization 
initiatives  supporting  cross  functional  applications 
including  CALS  [Continuous  Acquisition  and  Life-Cycle 
Support] ,  EC/EDI  [Electronic  Commerce/Electronic  Data 
Interchange],  and  Modeling  &  Simulation.  This  should 
include  application  of  the  Integrated  Data  Environment 
(IDE)  concept  and  technologies. 

6.  Reduce  costs  while  ensuring  the  effectiveness  of 
data/information  through  efficient  data  capture, 
collection,  processing,  storage,  and  dissemination. 

7.  Implement  a  Data  Administration  Program  which  includes 
procedures  for  standardizing  data,  promulgating  and 
enforcing  use  of  standard  data  elements,  and  oversight 
reviews  of  Service/Agency  programs. 

Some  of  these  actions,  such  as  develop  standard  definitions 

for  data,  are  already  underway  throughout  DoD.  Other  actions 

remain  to  be  implemented,  with  the  guidance  expected  in  the 

follow-on  Corporate  Information  Management  Operational  Plan 

(ASD-C3I,  1994). 

The  CIM  Strategic  Plan  is  accompanied  by  the 
Enterprise  Integration  Implementing  Strategy  (DISA-CFI&I, 
1994),  which  provides  a  description  of  the  approach  and 
initiatives  required  to  accomplish  the  plan's  goals.  The 
proposed  frameworks  for  achieving  Enterprise  Integration  (El) 
are  the  DoD  Enterprise  Model  and  the  Technical  Architecture 
Framework  for  Information  Management  (TAFIM) . 

The  DoD  Enterprise  Model  is  a  high-level  model  of  the 
DoD  as  an  enterprise,  and  consists  of  a  data  model  and  a 
function  model.  The  concept  of  an  Enterprise  Model  provides 
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the  means  for  describing  how  each  organization  will  fit  into 
the  DoD  Enterprise  (DISA-CFI&I,  1994,  p.  24)  .  Each  functional 
organization  is  expected  to  reengineer  their  processes  to 
conform  with  the  DoD  Enterprise  Model,  allowing  integration 
into  the  overall  DoD-wide  structure.  Figure  II.  1  shows  the 
top  level  of  the  DoD  Enterprise  Data  Model,  and  Figure  II. 2 
shows  the  top  level  of  the  DoD  Enterprise  Activity  Model. 

The  TAFIM  does  not  define  a  specific  system 
architecture;  it  provides  the  components  —  services, 
standards,  design  concepts,  equipment,  and  configurations  — 
that  will  guide  the  development  of  technical  architectures 
within  DoD.  The  TAFIM  is  independent  of  mission-specific 
applications  and  data  types,  and  therefore  promotes 
interoperability,  portability,  and  scalability.  Since  all  DoD 
information  systems  must  be  interoperable  at  some  time  in  the 
future,  the  use  of  the  TAFIM  now  will  allow  development  of 
systems  that  will  more  easily  reach  interoperability  in  the 
future.  (DISA-CFA,  1993,  p.  3) 

The  TAFIM  does  not  only  address  technical 
architectures.  The  data  architecture  and  the  application 
software  architecture  must  be  integrated  with  the  technical 
architecture  to  create  a  complete  information  system. 
Accordingly,  the  TAFIM  provides  some  discussion  of  each  of 
these  architectures  as  they  relate  to  the  technical 
architecture,  and  their  integration  through  the  use  of  the 
hierarchical  DoD  Information  Management  (IM)  Integration 


30 


'I'he  DoD  Enic.rpi  isc  Model 


I 


I 

I 


nSIAIIH 


Figure  II. 2  DoD  Enterprise  Activity  Model  -  Strategic  Level 
(DDI,  1993) 
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Model.  Figure  I I. 3  provides  a  view  of  the  IM  model.  The  CIM 
program  has  expanded  the  IM  model  to  add  two  levels,  and 
renamed  it  as  the  CIM  Integration  Architecture.  Figure  II. 4 
provides  a  view  of  this  new  version.  The  TAFIM  also  provides 
a  vision  for  DoD  Information  Management  (DISA-CFA,  1993,  p. 
61),  which  correlates  well  with  the  goals  of  the  Corporate 
Information  Management  Strategic  Plan, 

2.  DoD  Directives  and  Instructions 

The  DoD  Directives  and  Instructions  which  are  most 
applicable  to  information  and  data  management  are: 

Compatibility /■  Interoperability^  and  Integration  of 
Command,  Control,  Communications,  and  Intelligence  (C3I) 
Systems  (DoD  Directive  4630.5,  12  November  1992)  provides  the 
overall  directive  for  functional  and  technical  integration  of 
DoD  system  requirements  to  achieve  system  interoperability. 

Procedures  for  Compatibility,  Interoperability,  and 
Integration  of  Command,  Control,  Communications,  and 
Intelligence  (DoD  Instruction  4630.8,  18  November  1992) 

provides  the  specific  implementation  guidance  for 
accomplishing  the  requirements  of  the  related  DoD  Directive. 

Defense  Information  Management  (IM)  Program  (DoD 
Directive  8000.1,  27  October  1992)  establishes  the  DoD 

policies  for  the  implementation,  execution  and  oversight  of 
DoD  IM  Program.  All  of  the  policies  listed  within  this 
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Figure  II. 3  IM  Integration  Model 

(TAFIM,  Vol.l,  1993,  p.  28) 
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Figure  II. 4  CIM  Integration  Architecture 
(D.  Appleton,  1993,  p.  23) 
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directive  apply  to  NPS.  Some  of  the  policies  specifically 
address  information  and  data  management: 

1.  Data  and  information  are  corporate  assets.  The 
information  must  be  structured  to  allow  full 
interoperability  and  integration  throughout  DoD. 

2.  Functional  process  re-engineering  should  be  based  on  DoD- 
approved  activity  models  and  data  models. 

3.  The  entire  information  system  lifecycle  should  be  managed 
from  a  DoD-wide  perspective  to  ensure  cross-functional 
consistency  of  information. 

4.  Approved  DoD-wide  methods,  approaches,  models,  tools, 
data,  and  information  technology  should  be  used  wherever 
possible . 

5.  Standard  DoD  data  definitions  must  be  used  for  all 
information  systems. 

The  DoD  policy  to  treat  information  as  a  corporate  asset  is 
simply  a  reiteration  of  higher-level  guidance.  The 
requirement  to  use  a  structure  to  allow  DoD-wide  integration 
and  interoperability  leads  directly  to  data  element 
standardization,  which  is  specifically  addressed.  The  DoD- 
approved  activity  models  and  data  models  are  encompassed 
within  the  DoD  Enterprise  Model.  The  approved  DoD  methods  for 
working  with  the  activity  models  and  data  models  are  the  IDEFO 
and  IDEFIX  modeling  techniques.  These  modeling  techniques  and 
their  specific  modeling  languages  are  the  result  of  the  U.S. 
Air  Force's  Integrated  Computer  Aided  Manufacturing  (ICAM) 
program,  and  derive  their  name  from  that  program  —  ICAM 
Definition  Languages.  Activity  modeling  uses  IDEFO,  with  the 
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Activity  Modeling  Language  (AML) ;  data  modeling  uses  IDEFIX, 
with  the  Structural  Modeling  Language  (SML) (D.  Appleton, 
1993,  p.  158) 

This  directive  also  includes  a  listing  of  the 
principles  to  be  used  to  guide  the  implementation  of  the  DoD 
IM  Program.  Three  key  principles  are: 

1.  Information  systems  must  be  developed  using  process 
models  that  are  based  on  business  methods. 

2.  Data  definitions  must  be  standardized  DoD-wide. 

3 .  Data  entry  must  only  happen  once . 

The  first  principle  endorses  the  use  of  top-down  business 
planning  analysis  methodologies,  such  as  infomation 
engineering.  The  second  principle  is  simply  a  reiteration  of 
other  policy  statements.  The  third  principle  addresses  the 
issue  of  data  redundancy  within  organizational  information 
systems  that  are  not  integrated  or  interoperable,  thus 
preventing  single  data  entry  processing. 

DoD  DATA  ADMINISTRATION  (DoD  Directive  8320.1,  26 
September  1991)  provides  the  policies  for  data  administration 
throughout  DoD,  authorizes  the  promulgation  of  data  element 
standardization  procedures,  and  establishes  a  DoD  Information 
Resource  Dictionary  System  (DoD  IRDS) .  This  directive  is  one 
of  the  first  documents  revised  as  a  result  of  the  CIM 


^  The  IDEFO  and  IDEFlX  modeling  techniques  are  discussed 
in  greater  detail  in  Chapter  III. 
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Initiatives.  This  directive  has  two  sections  of  importance  — 
the  Concept  section  and  the  Policy  section. 

Seven  concepts  are  described  in  the  concept  section: 
four  concepts  address  the  importance  of  data  administration 
within  DoD,  two  concepts  address  the  tools  of  data 
administration,  and  one  concept  discusses  data  element 
standardization.  One  of  the  key  concepts  involves  the 
description  of  the  DoD  data  administration  tools: 

The  primary  tools  of  data  administration  are  an  IRDS  and 
a  functional  data  structure  and  rules.  That  structure  and 
the  rules  establish  a  framework  within  which  to  determine 
what  data  elements  should  be  standardized,  describe  how 
data  elements  should  be  grouped,  and  state  which  data 
elements  should  be  located  in  the  DoD  IRDS.  The 
functional  data  structure  is  determined  by  the  data  needs 
of  the  organization.  The  DoD  IRDS  is  used  to  define, 
structure,  and  maintain  metadata  for  data  administration. 
(DoD,  1991,  p.  3) 

Although  the  functional  data  structure  is  defined  by  the 
organization  at  the  local  level;  the  rules  are  promulgated  by 
DoD  in  DoD  Directive  8320.1-M-l  (See  below).  A  detailed 
description  of  the  DoD  IRDS  and  the  related  procedures  for  its 
use  are  also  provided  in  DoD  Directive  8320.1-M-l. 

The  directive's  concepts  must  be  considered  when 
implementing  the  directive's  policies  since  the  policies  are 
only  described  using  general  terms.  Three  of  the  policies 
which  provide  top-level  data  management  guidance  are: 

Implement  data  administration  aggressively  in  ways  that 
provide  clear,  concise,  consistent,  unambiguous,  and 
easily  accessible  data  DoD-wide,  and  that  minimize  the 
cost  and  time  required  to  transform,  translate,  or 
research  differently  described,  but  otherwise  identical, 
data. 
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standardize  and  register  data  elements  to  meet  the 
requirements  for  data  sharing  and  interoperability  among 
ISs  throughout  the  Department  of  Defense. 

Use  applicable  Federal,  national,  and  international 
standards  before  creating  DoD  standards  or  using  common 
commercial  practices. 

These  policies  provide  unequivocal  high-level  guidance  for  the 
use  of  standards  in  data  administration. 

The  DoD  DATA  ADMINISTRATION  directive  has  an 
accompanying  document,  DATA  ELEMENT  STANDARDIZATION  PROCEDURES 
(DoD  Directive  8320.1-M-l,  January  1993),  which  provides  the 
specific  procedures  for  developing,  approving  and  maintaining 
DoD  standard  data  elements.  This  directive  is  the  only 
document  that  specifies  the  actual  conditions  for  applying  the 
DoD  guidance  and  policy  with  respect  to  DoD-wide  data 
standardization.  The  specific  conditions  that  apply  to  any 
organization,  not  just  NFS,  are: 

1.  The  procedures  are  mandatory  for  use  after  January  1993 
for  all  new  information  system  development,  information 
system  modernization  that  affects  30%  or  more  of  the 
existing  lines  of  software  code,  or  the  addition  of  any 
new  data  elements  to  a  system. 

2.  Data  elements  in  existing  systems  do  not  need  to  be 
restructured  to  conform  to  DoD  standards  unless  the 
information  system  is  designated  as  a  DoD  migration 
system. 

There  are  some  exceptions  to  these  requirements,  but  they  deal 
with  special  cases  that  generally  do  not  apply  to  NFS  systems. 
As  a  result  of  these  conditions,  most  of  the  NFS  information 
systems  and  their  data  are  currently  exempt  from  meeting  the 
DoD  data  element  standards.  However,  the  other  DoD  policy 
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directives  foreshadow  a  future  migration  of  all  DoD  data  to 
DoD-wide  standard  data  elements  to  enable  better  functional 
integration  and  interoperability. 

C .  DEPARTMENT  OF  THE  NAVY  (DoN)  RULES ,  REGULATIONS 

STANDARDS,  AND  GUIDANCE 

The  DoN  guidance,  like  the  DoD-level  guidance,  implements 
higher-level  guidance  and  provides  specific  supplemental 
direction  when  required.  The  DoN  guidance  is  contained  in 
Secretary  of  the  Navy  (SECNAV)  Instructions  (SECNAVINST)  and 
Navy  Instructions  (OPNAVINST) . 

1.  Secretary  of  the  Navy  (SECNAV)  Instructions 

INFORMATION  RESOURCES  (IR)  PLANNING  (SECNAVINST 
5230. 9A,  16  October  1985)  provides  the  DoN  guidance  for 
conducting  long-range  strategic  information  resources  planning 
to  support  mission  accomplishment.  This  instruction 
specifically  implements  the  guidance  found  in  higher 
directives,  including  the  Federal  Government  level  guidance  in 
0MB  Circular  A-130.  One  of  the  key  components  in  this 
document  is  the  requirement  for  each  individual  DoN  component, 
such  as  NPS,  to  submit  a  Component  Information  Management  Plan 
(CIMP)  and  update  the  CIMP  annually.  The  CIMP  is  a  standard 
format  document  which  addresses  the  following  planning  areas; 
IRM  organization,  mission  requirements,  IS  architecture,  IRM 
objectives,  IS  resource  acquisitions,  and  resource 
requirements.  Information  Requirements  Plans  (IRP)  provide 
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more  detailed  discussion  of  the  individual  information 
requirements,  divided  into  functional  areas. 

The  other  key  SECNAV  Instruction  is  Life  Cycle 
Management  Policy  and  Approval  Requirements  for  Information 
Systems  Projects  (SECNAVINST  5231. 1C,  10  July  1992),  which 
also  addresses  a  requirement  for  components  to  submit  CIMPs  as 
part  of  the  IS  life  cycle  management  process. 

2.  Navy  Instmictions  (OPNAVINST) 

There  are  no  specific  OPNAV  Instructions  that  address 
strictly  information  management  or  data  management;  the  areas 
addressed  by  OPNAV  Instructions  are  Automated  Data  Processing 
(ADP)  security,  and  inventory  controls.  However,  the  Chief  of 
Naval  Operations  (CNO)  has  promulgated  new  guidance  (CNO, 
1994)  for  submitting  the  CIMP  based  on  three  drivers:  full 
Navy  participation  in  the  DoD  CIM  program,  integration  of 
active  and  reserve  IS,  and  use  of  client-server  and  other 
technologies  to  enhance  productivity. 

3 .  Naval  Postgraduate  School  Guidance 

NPS  has  two  instructions  related  to  information 
resources  management:  one  instruction  addresses  acquisition  of 
information  resources  and  implements  higher-level  guidance  on 
life-cycle  management;  the  other  instruction  addresses  ADP 
security. 

However,  there  are  other  potential  sources  of 
guidance.  The  NPS  Computer  Advisory  Board’s  (CAB)  draft  Naval 
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Postgraduate  School  Information  Systems  Vision  Statement 
(hereafter  NPS-IS  Vision)  (NPS-CAB,  1993)  describes  a  vision 
for  computing  and  information  technology,  and  includes  a 
strategy,  and  initial  implementation  goals.  The  proposed 
vision  statement  includes  an  integrated  approach  to  computing 
and  information  resources  management,  which  follows  the 
current  DoD  guidance.  The  proposed  vision  statement  also 
includes  a  centrally  managed  computer  architecture  using 
"fully-distributed  systems,  which  are  interconnected  to 
maximize  shared  utilization  of  campus  resources"  (NPS-CAB, 
1993)  .  One  of  the  key  proposed  strategies  is  the 
administrative  strategy.  This  proposed  strategy  implements 
the  vision  of  a  fully  integrated  system,  incorporating 
centralized  strategic  planning  and  decentralized  data 
administration . 

The  draft  Principles  for  NPS  Information  Resource 
Management  (NPS-IS,  1993)  are  modeled  directly  after  DoD's 
Principles  of  Information  Management,  found  in  DoD  Directive 
8000.1(D).  Several  of  these  proposed  principles  are  key  to 
the  future  of  data  management  at  NPS: 

1.  NPS  users  are  accountable  for  the  accuracy  of  the  data  in 
their  information  systems.  Each  information  system  is 
under  the  stewardship  of  a  functional  manager. 

2.  NPS  and  Navy  data  standards  are  invoked. 

3.  Data  will  be  entered  only  once. 

4.  All  data  maintained  by  any  organizational  unit  is 
considered  part  of  the  corporate  NPS  data,  and  will  be 
accessible  to  any  authorized  users. 
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These  proposed  principles  require  functional  managers  to  be 
responsible  for  data  management  within  their  systems, 
following  the  approved  data  standards,  and  correspond  to  the 
draft  NPS-IS  Vision's  espoused  strategy  of  decentralized 
maintenance  of  data  elements. 

D .  CHAPTER  SU14MARY 

The  preceding  overview  of  the  IRM  guidance  provided  at  all 
levels  of  NFS's  chain-of-command,  up  through  the  military  and 
Federal  Government  hierarchy,  reinforces  the  importance  of 
proper  information  and  data  management.  It  also  demonstrates 
the  renewed  emphasis  on  the  use  of  standards,  especially  data 
element  standards,  as  a  mechanism  to  achieve  enterprise-wide 
integration  and  interoperability. 

The  next  chapter  builds  on  some  of  this  guidance  in  the 
discussion  of  the  methodology  and  approaches  chosen  for  this 
research  project. 
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III.  RESEARCH  METHODOLOGY  AND  AUTOMATED  TOOLS 

This  chapter  provides  a  brief  discussion  of  the  system 
development  methodology  alternatives,  the  methodology  selected 
(information  engineering),  and  the  automated  tools  used. 

A.  SYSTEM  DEVELOPMENT  METHODOLOGIES 

A  study  on  data  management  practices  by  Dale  Goodhue, 
Judith  Quillard,  and  John  Rockart  (Sprague  and  McNurlin,  1993, 
p.  200)  points  out  three  traditional  approaches  to  enterprise¬ 
wide  data  management:  technical,  organizational,  or  business. 
The  technical  approach  uses  database  management  systems 
(DBMS),  data  dictionaries,  and  data  entity-relationship  (E-R) 
modeling.  The  organizational  approach  creates  data  and 
database  administrator  positions  and  formal  administrative 
policies  and  procedures  for  data  management.  The  business 
approach  uses  top-down,  business  planning  processes  which  tie 
data  requirements  to  business  objectives.  Examples  of 
business  approaches  are  Enterprise  Architecture  Planning 
(EAP) ,  Information  Engineering,  Business  Systems  Planning 
(BSP) ,  and  other  strategic  systems  planning 
methodologies.  Studies  by  C.J.  Coulson  (1982),  B.K.  Kahn 
(1983),  and  G.D.  Tilman  (1987)  show  that  the  technical  and 
organizational  approaches  are  inadequate;  therefore  the 
business  approaches  draw  more  attention  today. 
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A  top-down  business  approach  involves  top-management  in 
the  planning  process  and  focuses  first  on  the  organization's 
overall  goals  and  strategies. 

The  logic  here  is  that  above  all,  information  systems 
need  to  be  responsible  to  and  supportive  of  an 
organization's  basic  goals.  These  goals  should  be  the 
driving  force  behind  the  development  of  all  information 
systems.  (Senn,  1990,  p.  654) 

The  use  of  a  top-down  approach  creates  an  overall  framework 
for  developing  any  computerized  enterprise.  Systems  developed 
separately  still  fit  into  this  framework.  The  enterprise-wide 
(top-down)  approach  makes  it  possible  to  achieve  coordination 
among  these  separately  built  systems,  and  facilitates  the 
long-term  evolution  of  systems.  The  same  data  is  represented 
in  the  same  way  in  different  systems,  resulting  in  integration 
among  systems  where  needed.  All  the  business  approach 
methodologies  use  a  top-down  approach;  they  differ  only  in  the 
implementation  details  and  level  of  integration. 

1.  Enterprise  Architecture  Planning  (EAP) 

Enterprise  Architecture  Planning  (EAP)  is  Steven  H. 
Spewak's  process  "for  defining  the  top  two  layers  of  the 
Zachman  Information  Systems  Architecture  Framework".  (Spewak, 
1993,  p.  xxi)  The  Zachman  Framework  identifies  an  information 
systems  architecture  framework  consisting  of  three  kinds  of 
architectures  —  data,  process  (application),  and  network 
(technology) .  The  three  architectures  span  six  levels,  or 
phases;  these  levels  are  explained  using  an  analogy  to  the 
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process  of  planning,  drafting,  and  building  a  new  home.  The 
six  levels  are:  objectives/scope  (ballpark  view),  model  of 
the  business  (owner's  view),  model  of  the  information  system 
(designer '  s  view) ,  technology  model  (builder '  s  view)  ,  detailed 
representations  (out-of-context  view) ,  and  functioning  system. 
(Spewak,  1993,  p.  11-12) 

Since  EAP  only  deals  with  the  top  two  layers  of  the 
Zachman  Framework,  EAP  only  provides  a  high-level  blueprint  of 
the  data,  applications,  and  technology.  EAP  is  a  business- 
driven  or  data-driven  model  because  a  stable  business  model 
(independent  of  organizational  boundaries,  systems,  and 
procedures)  is  the  foundation  for  the  architectures;  the  data 
is  defined  first;  and  data  dependency  determines  the  sequence 
for  implementing  application  systems.  (Spewak,  1993,  p.  xxi) 
2.  Business  System  Planning  (BSP) 

Business  Systems  Planning  (BSP)  is  one  of  the  most 
widely  used  methods  for  information  systems  planning. 
Originally  developed  by  IBM  as  an  internal  tool,  BSP  is  now  a 
publicly  available  generalized  planning  methodology;  IBM  even 
prepares  manuals  and  training  courses  to  assist  firms  in  the 
proper  use.  BSP  treats  all  data  as  a  corporate  resource  which 
requires  the  investment  of  time  and  financial  resources,  and 
a  commitment  of  management  and  staff,  to  capture,  store,  and 
preserve  the  data.  BSP  uses  a  top-down  approach  to  define  the 
data  necessary  to  run  an  organization.  (Senn,  1990,  p.  661) 
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BSP  has  three  major  limitations.  First,  BSP  only 
focuses  on  existing  organizational  system  details,  with  little 
emphasis  on  requirements  for  improving  systems.  "...  BSP 
describes  what  is,  not  what  is  important."  (Senn,  1990,  p. 
662)  Second,  BSP  is  very  effective  in  identifying  current 
information  systems  requirements.  However,  BSP  does  not 
provide  an  automated  method  for  incorporating  long-range  needs 
into  the  analysis  results.  Finally,  completion  of  a  BSP  study 
requires  an  inordinate  amount  of  time.  The  analysts  must 
interview  a  sizable  number  of  managers  in  order  to  develop  a 
broad  and  comprehensive  understanding  of  the  organization’s 
requirements.  Next,  the  analysts  must  synthesize  the  data, 
which  is  a  challenging  task.  (Senn,  1990,  p.  662) 

3.  IDEFO  and  IDEFlX 

The  U.S.  Air  Force  has  a  program  for  Integrated 
Computer  Aided  Manufacturing  (ICAM) ,  which  developed  a  series 
of  modeling  techniques  during  the  1970s.  The  Air  Force  uses 
these  modeling  techniques,  known  as  the  IDEF  (ICAM  Definition) 
techniques,  to  produce  "function  models"  (IDEFO),  "information 
(data)  models"  (IDEFl) ,  and  "dynamics  models"  (IDEF2) .  A 
function  model  is  a  structured  representation  of  the 
functions,  activities  or  processes  within  the  modeled  system 
or  subject  area.  An  information  model  represents  the 
structure  and  semantics  of  information  within  the  modeled 
system  or  subject  area.  A  dynamics  model  represents  the  time- 
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varying  behavioral  characteristics  of  the  modeled  system  or 
subject  area.  As  a  result  of  another  U.S.  Air  Force  program, 
the  Integrated  Information  Support  System  (I^S^) ,  IDEFl  is  now 
IDEFIX,  an  enhanced  version  of  IDEFl.  Both  IDEFO  and  IDEFIX 
are  now  Federal  Information  Processing  Standards  (FIPS)^  as  a 
result  of  their  adoption  by  the  Department  of  Defense  for  use 
with  the  Corporate  Information  Management  (CIM)  initiatives. 
(NIST,  1993a,  p.  i) 

IDEFO  (Integration  DEFinition  language  0),  based  on 
Douglas  T.  Ross'  and  SofTech,  Inc.'s  SADT™  (Structured 
Analysis  and  Design  Technique™)  ,  includes  both  a  definition 
of  a  graphical  modeling  language  (syntax  and  semantics)  and  a 
description  of  a  comprehensive  methodology  for  developing 
models.  IDEFO  produces  a  model  that  consists  of  a 
hierarchical  series  of  cross-referenced  diagrams,  text,  and  a 
glossary.  The  two  primary  modeling  components  are  the 
functions  and  the  data  (objects)  that  inter-relate  those 
functions.  The  IDEFO  methodology  also  includes  procedures  and 
techniques  for  developing  and  interpreting  many  different 
kinds  of  models,  including  models  for  data  gathering,  diagram 
construction,  review  cycles,  and  documentation. 

(NIST,  1993a,  p.  ii) 


The  IDEFO  modeling  technique  is  promulgated  as  FIPS  183. 
The  _  IDEFIX  modeling  technique  is  promulgated  as  FIPS  184. 
Copies  of  the  FIPS_  are  available  for  sale  from  the  National 
technical  Information  Service,  U.  S.  Department  of  Commerce. 
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IDEFIX  is  a  semantic  data  modeling  technique,  based  on 
relational  theory  and  entity-relationship  models,  which  uses 
a  "conceptual  schema"  to  provide  a  single  integrated 
definition  of  the  data  within  an  enterprise.  The  conceptual 
schema  definition  is  independent  of  how  the  data  is  physically 
stored  or  accessed.  The  primary  objective  of  the  conceptual 
schema  is  data  integration  through  a  consistent  definition  of 
the  meanings  and  interrelationship  of  data.  The  primary 
components  of  IDEFIX  are  data  entities,  data  entity 
attributes,  and  the  relationships  between  data  entities. 
(NIST,  1993b,  p.  iii) 

The  most  significant  limitation  of  the  IDEF  techniques 
is  the  lack  of  integration  between  the  methodologies. 
Although  each  technique  —  information  (data) ,  function,  and 
dynamics  —  provides  integration  within  its  methodology,  there 
is  no  integration  of  the  models  developed  by  each  technique. 

4 .  Information  Engineering 

Information  engineering  is  a  structured  methodology 
that  is  recognized  as  one  of  the  leading  enterprise  wide  data 
analysis  methodologies.  Enterprise  modeling  requires  an 
effective  methodology.  An  effective  enterprise  modeling 
methodology  uses  one  technique  that  consistently  states  the 
enterprise's  goals,  purpose,  context,  strategy,  markets, 
threats  and  opportunities,  critical  success  factors,  controls, 
policies,  procedures,  and  business  rules.  To  be  effective. 
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the  technique  allows  users  at  every  level  to  view  the 
organization  from  their  perspective  at  any  time.  The  views 
are  integrated  to  allow  mapping  of  functions,  information 
states,  organization,  resources,  control,  and  security.  Other 
requirements  for  enterprise  modeling  include  effectively 
recording  the  state  and  impact  of  the  external  environment; 
being  able  to  integrate  enterprises  physically  distributed; 
and  being  able  to  incorporate  technology-independent  logical 
modeling.  Information  engineering  incorporates  this  concept 
of  enterprise  modeling  which  differentiates  it  from 
conventional  methodologies.  (Clark,  1992,  p.  31) 

The  information  engineering  methodology  has  three  main 
variants:  the  classical  information  engineering  approach,  the 
business  system  implementation  approach,  and  the  rapid 
application  development  (RAD)  approach.  The  classical 
approach  includes  seven  stages:  Information  Strategy  Planning 
(ISP),  Business  Area  Analysis  (BAA),  Business  System  Design 
(BSD) ,  Technical  Design  (TD) ,  Construction,  Transition,  and 
Production.  The  business  system  approach  is  similar  to  the 
classical  approach,  except  that  the  Business  System  Design, 
Technical  Design,  and  Construction  phases  are  treated  as 
simply  one  stage.  The  rapid  development  approach  is 
significantly  different  due  to  changes  in  the  duration  and 
cutoff  points  of  each  stage  and  an  emphasis  on  group 
development  techniques.  RAD  stages  are:  Information  needs 
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structuring  (INS),  Requirements  Planning  (RP) ,  User  Analysis 
and  Design  (UD) ,  Construction,  and  Cutover. 

The  individual  techniques  and  methods  used  by  the 
information  engineering  methodology  include:  flow  charting, 
functional  decomposition,  modular  programming,  structured 
programming,  structured  design,  structured  analysis,  strategic 
data  planning,  data  modeling,  and  object-oriented  analysis  and 
design.  While  many  of  the  individual  techniques  used  in  the 
information  engineering  methodology  originated  elsewhere, 
information  engineering  clearly  defines  how  the  deliverables 
from  one  technique  relate  to  the  deliverables  from  other 
techniques  within  and  across  development  phases.  Thus  the 
information  engineering  methodology  provides  the  integration 
of  the  data,  activities,  and  interactions  missing  in  the  other 
approaches . 

The  information  engineering  methodology  provides  the 
basis  for  many  automated  tools.  One  of  the  best  known  is 
Texas  Instruments'  (TI)  Computer  Aided  Software  Engineering 
(CASE)  tool  Information  Engineering  Facility™  (lEF™),  which 
implements  the  classic  information  engineering  methodology 
approach.  lEF™  does  not  have  a  capability  to  directly 
integrate  IDEFO  and  IDEFlX  models.  However,  a  companion  tool, 
TI's  Business  Design  Facility™  (BDF™) ,  can  create  or  import 
IDEFO  and  IDEFlX  models  and  port  them  directly  to  lEF™. 

The  integration  capabilities  of  the  information 
engineering  methodology,  coupled  with  the  ready  availability 
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of  automated  support,  provide  significant  incentive  for 
selecting  information  engineering  as  the  methodology  of 
choice . 

B.  INFORMATION  ENGINEERING  METHODOLOGY 

James  Martin  and  Clive  Finkelstein  first  introduce  the 
information  engineering  methodology  in  the  early  1970s  as  a 
data-driven  strategic  information  systems  (IS)  development 
methodology  supporting  the  entire  IS  lifecycle  (Zeiders,  1990, 
p.  4)  The  information  engineering  methodology  has  seen 
multiple  refinements  since  its  introduction,  and  is  now  a 
comprehensive  system  development  methodology  which  involves 
the  application  of  formal  structured  techniques  to  an 
enterprise  as  a  whole  in  order  to  maximize  the  value  of 
information  systems  in  use  throughout  the  enterprise  (Martin, 
Book  II,  1990,  p.  1),  The  methodology  supports  information 
systems  integration  through  the  use  of  a  common  repository  of 
data  models,  process  models,  and  other  design  information. 
The  common  repository  facilitates  the  identification  of  common 
data  entities  and  common  rules,  thus  supporting  reusable 
designs  and  reusable  code  (Martin,  Book  II,  1990,  p.  1) . 

Martin  describes  information  engineering  as  a  two-sided 
pyramid  with  four  basic  levels:  strategy  (Information  Strategy 


Clive  Finkelstein  provides  a  concise  chronology  of  the 
evolution  of  Information  Engineering  in  his  book  An 
Introduction  to  Information  Engineering  (Finkelstein,  1989, 
Ch .  2 )  . 
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Planning),  analysis  (Business  Area  Analysis),  design  (System 
Design) ,  and  construction.  One  side  of  the  pyramid  relates  to 
data,  and  the  other  side  of  the  pyramid  relates  to  activities, 
or  processes.  Figure  III.l  provides  an  illustration. 
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Figure  III.l  Information  Systems  Pyramid 
(Martin,  Book  I,  1989,  p.  4) 


The  four  levels  of  the  pyramid  represent  the  four  stages 
or  phases  of  information  engineering  implementation,  and  are 
discussed  in  greater  detail  below: 

1.  Information  Strategy  Planning  (ISP) 

Concerned  with  top  management  goals  and  critical  success 
factors.  Concerned  with  how  technology  can  be  used  to 
create  new  opportunities  or  competitive  advantages.  A 
high  level  overview  is  created  of  the  enterprise,  its 
functions,  data,  and  information  needs.  (Martin,  Book  I, 
1989,  p.  13) 

The  information  strategy  plan  maps  the  basic  functions 
of  the  enterprise  and  produces  a  high-level  model  of  the 
enterprise,  its  departments,  its  functions,  and  its  data. 
(Martin,  Book  I,  1989,  p.  102) 

The  Information  Strategy  Planning  phase  further 

subdivides  into  two  areas  —  Strategic  Information  Planning 

and  Enterprise  Modeling.  Each  of  these  areas  is  itself  made 

up  of  several  key  components  (Martin,  Book  II,  1990,  p.  13) : 

a.  Strategic  Information  Planning 

Strategic  Information  Planning  contains  the 
planning  issues  which  most  directly  concern  top  management. 

(1)  Analysis  of  Goals  and  Problems .  During  this 
analysis  phase,  a  structured  model  of  the  enterprise's 
strategy,  mission,  objectives,  goals,  and  problems  and  their 
association  with  specific  organizational  units,  information 
needs,  and  information  systems  is  created. 

(2)  Critical  Success  Factor  Analysis .  During  this 
analysis  phase,  those  areas  of  the  enterprise  which  must 
operate  properly  to  achieve  enterprise  success  are  identified. 
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The  analysis  includes  identification  of  the  critical 
assumptions,  the  critical  information  needs,  and  the  critical 
decisions  requiring  IS  support. 

(3)  Technology  Impact  Analysis.  During  this 
analysis  phase,  the  business  opportunities  and  threats 
provided  by  the  continuing  evolution  of  technology  are 
identified  and  prioritized. 

(4)  Strategic  System  Vision.  During  this  phase, 
methods  for  making  the  organization  more  competitive  through 
the  strategic  use  of  information  systems  and  information 
systems  technology  are  examined.  Charles  Wiseman  has 
classified  these  methods  as  strategic  thrusts,  dividing  them 
into  five  categories:  Differentiation,  Cost,  Innovation, 
Growth,  and  Alliance.  Additionally,  each  category  can  have 
offensive  or  defensive  modes  (Martin,  Book  II,  1990,  p.  134) . 

b.  Enterprise  Modeling 

Enterprise  Modeling  contains  the  planning  issues 
which  most  directly  concern  the  top  level  information  system 
planners . 

(1)  Overview  Model.  First,  a  hierarchical  map  of 
the  business  functions  and  their  associations  with 
organizational  units,  the  physical  location,  and  the  data 
entities  is  created.  This  generally  consists  of  a  set  of 
computerized  matrices. 
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(2)  Entity-Relationship  (E-R)  Modeling.  A  diagram 
or  chart  of  the  data  entities  and  their  associations  or 
relationships  with  each  other,  and  with  the  business 
functions,  is  created.  Clustering  analysis  of  the  data 
entity/business  function  relationships  is  also  performed. 

2.  Business  Area  Analysis  (BAA) 

Concerned  with  what  processes  are  needed  to  run  a 
selected  business  area,  how  these  processes  interrelate, 
and  what  data  is  needed.  (Martin,  Book  I,  1989,  p.  13) 

During  the  Business  Area  Analysis  phase,  the  models 

created  during  the  Information  Strategy  Planning  stage  are 

refined  in  greater  detail.  The  analysis  is  conducted  through 

the  development  of  two  types  of  model  sets  —  data  models,  and 

process  (or  function)  models: 

a.  Data  Modeling 

The  Data  Entity-Relationship  Diagrams  created 
during  the  Information  Strategy  Planning  stage  are  refined  by 
concentrating  on  a  single  business  area  at  a  time.  Each 
business  area  can  be  either  a  pre-defined  grouping  of  business 
functions  and  data,  or  a  clustering  of  functions  and  data 
determined  during  the  Information  Strategy  Planning  stage. 
The  refined  E-R  diagrams  then  become  the  data  model,  and  are 
fully  normalized  at  this  stage.  An  analysis  of  the 
interrelationships  between  the  data  and  the  processes, 
describing  which  processes  create,  read,  update,  or  delete 
data,  is  also  conducted,  through  the  use  of  matrices. 
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b.  Process  Modeling- 

The  process  modeling  consists  primarily  of  a 
Process  Decomposition  Diagram,  which  provides  a  detailed 
hierarchical  view  of  each  business  function  identified  during 
the  Information  Strategy  Planning  stage.  Additional  modeling 
includes  a  Process  Dependency  Diagram,  which  helps  identify 
the  chronological  dependency  and  flow  of  processes  (similar  to 
data  flow  diagrams,  but  without  showing  the  actual  data  in  the 
flows) . 

3.  System  Design 

Concerned  with  how  selected  processes  in  the  business 
area  are  implemented  in  procedures  and  how  these 
procedures  work.  Direct  end-user  involvement  is  needed  in 
the  design  of  procedures.  (Martin,  Book  I,  1989,  p.  13) 

During  the  System  Design  phase,  the  procedures 

required  to  implement  the  elementary  processes  are  determined 

and  the  user  interfaces  (screens,  reports,  layout)  are 

designed.  This  phase,  as  well  as  the  following  Construction 

phase,  is  generally  accomplished  using  automated  assistance  in 

the  form  of  specific  CASE  or  integrated  CASE  (I-CASE)  tools. 

This  phase  is  typically  characterized  by  heavy  end-user 

involvement  in  the  design  of  user  interfaces. 

a.  Business  System  Design 

The  objective  of  Business  System  Design  is  the 

definition  of  the  user  interactions  with  the  information 

system  needed  to  conduct  the  business  activities  identified 

during  the  Business  Area  Analysis  phase.  This  involves  the 
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establishment  of  standards,  the  determination  of  procedures 
required  to  implement  the  elementary  processes,  the 
specification  of  user  navigation  through  the  procedures,  and 
the  design  of  external  user  interfaces  (TI,  1988,  p.  300) . 

Jb.  Technical  Design 

Technical  Design  encompasses  the  environmental 
considerations  of  the  target  operating  environment,  including 
the  particular  hardware  and  software  implementations. 

4 .  Construction 

Implementation  of  the  procedures  using,  where  practical, 
code  generators,  fourth-generation  languages,  and  end-user 
tools.  Design  is  linked  to  construction  by  means  of 
prototyping.  (Martin,  Book  I,  1989,  p.  13) 

The  Construction  phase  implements  the  results  of  the 
Design  phase  by  converting  the  design  specifications  into 
software  code.  The  software  code  is  tested,  as  is  the 
hardware  and  all  inter-connections.  The  implementation 
procedures  for  the  new  system  are  developed,  the  training 
requirements  are  developed  and  implemented,  the  user  and 
technical  documentation  is  prepared,  and  the  long  term 
maintenance  requirements  are  determined. 

a .  Construction 

The  specific  code  for  the  target  environment  is 
developed,  either  manually,  or  using  an  automated  code 
generator.  Initial  testing  of  the  software  code  is  performed. 
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b ,  Transi tion 


Transition  in  an  information  engineering 
environment  is  similar  to  transition  in  a  non-information 
engineering  environment  (Martin,  Book  II,  1990,  p.  377) .  The 
information  system  equipment  is  installed,  data  is  ported  to 
the  new  system,  users  are  trained,  and  the  new  system  is 
implemented.  Implementation  will  involve  one  or  more  of 
several  different  methods  of  conversion,  including  direct 
cutover,  parallel  processing,  or  phased  transition, 
c.  Production 

Production  refers  to  the  development  of  operating 
and  maintenance  procedures  and  administrative  policies.  These 
include  procedures  and  policies  for  normal  system  operation, 
restart  and  recovery  operations,  security,  audit,  and  periodic 
maintenance  (Martin,  Book  III,  1990,  p.  395) . 

C.  TEXAS  INSTRUMENTS’  INFORMATION  ENGINEERING  FACILITY  ™ 

Texas  Instrxaments '  Information  Engineering  Facility™ 
(lEF™)  is  an  integrated  Computer  Aided  Software  Engineering 
(I-CASE)  tool  that  implements  the  information  engineering 
concepts  expressed  by  James  Martin  in  his  publications,  and 
refined  by  James  Martin  Associates  (TI,  1988) .  Texas 

Instruments  (TI)  primarily  targets  mainframe  application 
environments  (currently  CICS,  IMS/DC,  TSO,  and  MVS/Batch,  with 
others  under  development)  with  mainframe  or  PC  based 
development  environments  (Clark,  1992,  p.  81) .  lEF™ 
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components  implement  the  underlying  information  engineering 
methodology  through  the  use  of  a  central  encyclopedia  or  data 
repository  and  toolsets  for  the  planning,  analysis,  design, 
and  construction  phases  of  the  information  engineering 
lifecycle.  Figure  III. 2  provides  a  graphic  illustration  of 
the  IEF™'s  support  for  information  engineering. 

1 .  Enterprise  Integration 

One  of  the  strengths  of  the  IFF™  CASE  tool  is  the 
vertical,  horizontal,  and  cross-enterprise  integration 

maintained  throughout  the  product.  Each  toolset  is 
interlocked,  providing  integration  "within  each  stage  of  the 
system  life  cycle,  throughout  all  stages  of  the  system  life 
cycle,  and  across  the  individual  life  cycles  of  all  systems". 
(TI-I,  1990,  p.  6)  Figure  III. 3  provides  a  graphical 
depiction  of  IEF™'s  vertical  and  horizontal  integration, 
a.  VBrtical  Integration 

Vertical  integration  maintains  integrity  and 
consistency  from  stage  to  stage  through  tight  coupling  of  the 
high-level  specifications  developed  in  the  earlier  stages 
(Planning  and  Analysis)  and  the  detailed  specifications 
developed  in  the  later  stages  (Analysis  and  Design)  (TI-I, 
1990,  p.  7).  Figure  III. 2  also  shows  some  of  the  coupling 
between  stages. 
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Figure  III. 2  lEF™  Support  for  Information  Engineering 
(TI,  1990,  p.  10) 
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Figure  III. 3  lEF™  Vertical  and  Horizontal  Integration 
(TI,  1989,  p.  12) 


(1)  Information  Strategy  Planning.  The  Planning 
Toolset  produces  deliverables  primarily  targeted  at  top-level 
management.  These  deliverables  provide  documentation  about 
the  enterprise:  a  mission  statement;  an  information  needs  map; 
a  list  of  objectives,  strategies,  and  critical  success  factors 
by  organizational  unit;  an  organizational  hierarchy  structure 
diagram;  a  high-level  Entity  Relationship  Diagram  (data 
model) ;  an  overall  Function  Hierarchy  Diagram  (activity 
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model) ;  a  set  of  Function  Dependency  Diagrams  (interaction 
model);  and  other  supporting  matrices.  (TI-MT,  1992,  p.  15) 

(2)  Business  Area  Analysis.  The  Analysis  Toolset 
produces  deliverables  targeted  at  end  users.  The  deliverables 
include  the  same  deliverables  from  the  Planning  Toolset;  the 
only  difference  in  the  deliverables  is  the  level  of 
abstraction  —  the  Analysis  Toolset  provides  significantly 
greater  detail. 

(3)  Business  System  Design.  The  Design  Toolset 
also  produces  deliverables  targeted  at  end  users,  but  at  the 
next  lower  level  of  abstraction.  The  deliverables  include  a 
set  of  procedures  and  data  views  for  each  business  system,  and 
a  set  of  user  screen  and  report  layouts. 

(4)  Technical  Design.  The  Design  Toolset  produces 
deliverables  targeted  at  trained  information  systems 
professionals.  The  deliverables  consist  of  a  set  of  Data 
Structure  Lists  and  target  environment-specific  implementation 
details  after  the  model  has  been  tailored  to  a  specific  data 
base  management  system. 

(5)  Construction.  The  Construction  Toolset 
produces  100%  of  the  code  required  for  execution  of  the 
application. 

b.  Horizontal  Integration 

Horizontal  integration  maintains  integrity  within 
each  stage,  by  maintaining  integrity  between  diagrams,  tables 
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and  lists.  Through  horizontal  integration,  consistency  is 
maintained  among  the  three  components  —  data,  activities,  and 
interactions  —  at  each  stage  of  the  system  life  cycle.  The 
key  to  IEF™'s  horizontal  integration  is  the  assignment  of  a 
single  unique  definition  to  each  concept  that  is  then  shared 
among  all  the  tools  (TI,  1989,  p.  6) .  Figure  III. 4  provides 
a  graphical  display  of  IEF™'s  horizontal  integration. 

(1)  Data.  The  term  data  represents  all  concepts 
that  exist  in  a  real  or  abstract  sense  in  the  enterprise 
environment;  examples  for  NFS  include  students,  faculty 
members,  and  classes. 

(2)  Activities .  The  term  activities  represents 
all  functions  or  processes  that  occur  within  the 
organizational  environment,  such  as  a  student  attends  classes 
or  a  faculty  member  conducts  research . 

(3)  Interaction.  The  term  interaction  represents 
how  activities  affect  data,  such  as  how  a  student  completing 
a  course  affects  the  student  by  requiring  creation  of  a 
student  grade. 

c.  Cross-Enterprise  Integration 

Cross-enterprise  integration  ensures  consistent 
definitions  of  data  and  activities  across  all  functions  of  the 
organization,  at  any  level  of  detail  (level  of  abstraction) 
that  is  provided  (TI,  1989,  p.  7) .  This  consistency 
throughout  the  organization  is  achieved  through  the  use  of  a 
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(TI,  1990,  p.  13) 
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central  comprehensive  repository  of  systems  information,  which 
in  lEF™  is  known  as  the  Central  Encyclopedia.  The  Central 
Encyclopedia,  or  Host  Encyclopedia,  is  essentially  an  IBM  DB2™ 
system  development  relational  data  base  maintained  on  a 
mainframe  using  the  MVS  operating  system.  The  Host 
Encyclopedia  is  a  schema,  in  the  form  of  a  highly  flexible 
system  development  model,  that  connects  the  information 
engineering  system  concepts  together.  The  Host  Encyclopedia 
defines  all  of  the  generic  classes  of  objects  in  the  lEF™ 
architecture  (such  as  subject  areas,  entity  types,  functions, 
and  processes)  and  details  their  relationships  to  one  another. 
Figure  III. 5  provides  a  simplified  view  of  the  Host 
Encyclopedia  and  its  relationship  to  the  modeling  objects. 

2 .  Toolsets 

lEF™  provides  a  number  of  graphical  modeling  tools 
divided  into  subsets  that  correspond  to  the  principal  stages 
in  the  information  engineering  methodology.  The  toolsets  are: 

(Information  Strategy  Planning)  ,  Analysis  (Business 
Area  Analysis),  Design  (Business  System  Design/Technical 
Design),  and  Construction  (Technical  Design/Construction) ; 
other  toolsets  provide  interfaces  to  the  Central  Encyclopedia 
or  provide  overall  functions.  Some  of  the  tools  are  used  in 
more  than  one  toolset,  which  supports  the  transition  from  a 
high  level  of  abstraction  to  a  more  detailed  view  of  the 
organization  as  the  modeling  progresses.  All  the  toolsets 


66 


Figure  III. 5  Central  Repository  of  Modeling  Objects 
(TI,  1992,  p.  65) 


provide  access  to  a  comprehensive  list  of  reports,  which  can 
be  displayed,  printed,  or  separately  saved  to  a  file.  A  brief 
description  of  the  available  tools  in  each  toolset  is  provided 
in  Appendix  C  (TI-8072,  1990;  TI-8024,  1990;  TI-8040,  1990) . 
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IV.  ANALYSIS  OF  NFS  ENTERPRISE  INFORMATION  ARCHITECTURE 

This  chapter  provides  an  analysis  of  the  Naval 
Postgraduate  School  (NPS)  enterprise  information  architecture. 
The  analysis  of  the  Naval  Postgraduate  School's  information 
architecture  uses  James  Martin's  variant  of  the  classical 
information  engineering  methodology  as  a  guideline.  The  Texas 
Instriaments'  Computer  Aided  Systems  Engineering  (CASE)  tool 
Information  Engineering  Facility™  (lEF™)  is  an  automated 
implementation  of  Martin's  methodology,  and  provides  support 
for  the  analysis.  This  chapter  also  provides  a  discussion  of 
the  financial  and  personnel  constraints  for  implementation  of 
any  new  data  management  architecture. 

A.  NAVAL  POSTGRADUATE  SCHOOL  BACKGROUND 

The  Naval  Postgraduate  School  catalog  provides  an  overview 
statement  of  the  organization's  purpose: 

The  Naval  Postgraduate  School  is  an  academic  institution 
whose  emphasis  is  on  study  and  research  programs  relevant 
to  the  Navy's  interests,  as  well  as  to  the  interests  of 
other  arms  of  the  Department  of  Defense.  The  programs  are 
designed  to  accommodate  the  unique  requirements  of  the 
military.  (NPS,  1994) 

The  organization's  mission  statement  is  more  explicit  with 
respect  to  the  educational  objectives: 

The  mission  of  the  Naval  Postgraduate  School  is  to 
provide  advanced  professional  studies  at  the  graduate 
level  for  military  officers  and  defense  officials  from  all 
services  and  other  nations.  The  school's  focus  is  to 
increase  the  combat  effectiveness  of  the  armed  forces  of 
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the  United  States  by  providing  quality  education  which 
supports  the  unique  needs  of  the  defense  establishment. 
(NPS,  1994) 

An  expanded  mission  statement,  which  more  accurately  reflects 
the  dual  roles  of  education  and  research,  exists  in  Secretary 
of  the  Navy  (SECNAV)  INSTRUCTION  1524  (May  23,  1986) : 

The  Naval  Postgraduate  School  exists  for  the  sole 
purpose  of  increasing  the  combat  effectiveness  of  the  Navy 
and  Marine  Corps.  It  accomplishes  this  by  providing  post¬ 
baccalaureate  degree  and  nondegree  programs  in  a  variety 
of  subspecialty  areas  not  available  through  other 
educational  institutions.  NPS  also  supports  the 
Department  of  the  Navy  through  the  continuing  programs  of 
naval  and  maritime  research  and  through  the  maintenance  of 
an  expert  faculty  capable  of  working  in,  or  as  advisors 
to,  operational  commands,  laboratories,  systems  commands, 
and  headquarters  activities  of  the  Navy  and  Marine  Corps. 
(NPS,  1994) 

The  Naval  Postgraduate  School's  1994  Catalog  is  the  source  for 
the  following  background  information  on  the  school's  structure 
and  organization: 

The  Naval  Postgraduate  School  is  administered  as  an 
activity  within  the  Department  of  the  Navy,  and  is  funded  by 
the  Congress  of  the  United  States.  A  Graduate  Education 
Review  Board  (GERB) ,  chaired  by  the  Chief  of  Naval  Operations, 
meets  annually  to  provide  guidance  and  direction  for  the 
Navy's  graduate  education  program.  The  GERB  reviews  the 
adequacy  and  stability  of  resources  and  student  input,  and 
other  matters  of  potential  interest,  and  is  based  on  the 
annual  report  of  the  Graduate  Education  Review  Group  (GERG) . 
A  Board  of  Advisors,  composed  of  distinguished  professionals 
from  all  walks  of  life,  annually  assesses  the  Naval 
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Postgraduate  School's  mission  effectiveness,  and  evaluates 
future  plans,  as  part  of  their  charter  to  assist  the 
Superintendent  on  strategic  matters  of  the  Navy's  Graduate 
Education  Programs.  The  Navy's  fully-funded  graduate 
education  program  includes  78  different  curricula,  35  at  NPS 
and  36  at  over  62  civilian  institutions,  to  support  71 
military  billet  subspecialty  codes. 

The  Superintendent  of  the  Naval  Postgraduate  School  is  a 
flag  officer  of  the  line  of  the  U.S.  Navy.  In  addition  to 
serving  as  the  NPS  administrator,  the  Superintendent  is  the 
academic  coordinator  for  all  graduate  education  programs  in 
the  Navy,  including  fully  funded  graduate  education  programs 
at  the  Naval  War  College  and  civilian  institutions,  and  the 
Area  Coordinator  for  Naval  Subarea  Six.  The  Superintendent's 
principal  assistant  is  the  Provost/Academic  Dean,  who  is  the 
ranking  member  of  the  civilian  faculty.  The  other  principal 
assistants  in  the  administrative  staff  include  two  military 
positions  and  four  academic  positions. 

Members  of  the  faculty  are  organized  into  eleven  Academic 
Departments  and  four  interdisciplinary  Academic  groups,  each 
supervised  by  a  chairman.  Over  80%  of  the  faculty  are 
civilians  of  varying  experience  levels;  the  remainder  are 
military  officers. 

Eleven  Curricular  Offices,  staffed  by  military  officers 
(Curricular  Officers)  and  civilian  faculty  members  (Academic 
Associates),  serve  three  functions: 
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1.  Academic  counseling  and  military  supervision  of  officer 
students 

2.  Curriculum  development  and  management  to  ensure 
attainment  of  professional  and  academic  objectives 

3.  Liaison  with  curricular  sponsor  representatives 
Students,  grouped  by  curricular  program,  are  assigned  to  one 
of  the  Curricular  Offices  for  program  supervision  and  for 
academic  and  professional  counseling.  Numerous  types  of 
individuals  attend  the  Naval  Postgraduate  School  as  students, 
including  Naval  officers,  other  U.S.  military  officers, 
international  military  officers,  and  civilian  employees  of  the 
U.S.  Government.  The  Curricular  Officers  ensure  their 
curricula  meet  Navy  requirements,  and  ensure  proper 
administrative  operation  of  their  assigned  offices.  The 
Academic  Associates  ensure  the  integrity  and  academic 
soundness  of  the  academic  programs  within  each  curriculum. 
Figure  IV. 1  presents  the  NPS  organizational  hierarchy. 

The  Naval  Postgraduate  School  also  serves  as  the  host  for 
a  variety  of  tenant  activities,  including  the  Defense 
Resources  Management  Institute  (DRMI),  a  DoD  sponsored 
educational  institution. 

B.  NPS  ENTERPRISE  INFORMATION  ARCHITECTURE  ANALYSIS 

The  analysis  of  the  NPS  enterprise  follows  the  procedural 
steps  of  James  Martin's  version  of  the  information  engineering 
methodology.  The  Texas  Instruments  (TI)  Computer  Aided 
Software  Engineering  (CASE)  tool  Information  Engineering 
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Facility™  (lEF™)  provides  automated  analytical  support.  The 
scope  of  the  analysis  includes  tasks  defined  within  the  first 
two  phases  of  the  information  engineering  methodology  — 
Information  Strategy  Planning  (ISP)  and  Business  Area  Analysis 
(BAA)  .  The  bulk  of  the  research  concentrates  on  the  first 
phase,  Information  Strategy  Planning.  However,  this  research 
does  not  attempt  to  completely  perform  the  procedures 
specified  for  either  of  these  two  phases;  to  do  so  properly 
within  the  NPS  organizational  environment  requires 
significantly  more  resources  than  are  currently  available. 
The  discussion  of  each  information  engineering  methodology 
phase  identifies  all  the  tasks,  and  the  expected  level  of 
detail,  that  would  normally  be  performed  as  part  of  that 
phase.  Analysis  comments  address  incomplete  tasks  when 
appropriate. 

1.  Information  Strategy  Planning  (ISP) 

In  simplest  form,  the  objectives  of  the  analysis  in 
the  Information  System  Planning  (ISP)  stage  are: 

1.  Define  the  structure  of  the  enterprise. 

2.  Define  the  information  requirements  of  the  enterprise. 

3.  Define  the  activities  performed  by  the  enterprise. 

4.  Define  the  data  required  to  perform  the  activities. 

5.  Group  the  activities  and  data  into  natural  business 
systems . 
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6.  Forecast  the  required  hardware  and  software  facilities. 

7 .  Supply  detailed  information  supporting  the  Information 
Strategy  Plan.  (lEF™,  1991) 

The  deliverables  for  the  ISP  phase  include  four  specific 
diagrams  —  the  Organizational  Hierarchy  Diagram  (OHD) ,  the 
Function  Hierarchy  Diagram  (FHD),  the  Function  Dependency 
Diagram  (FDD) ,  and  the  Entity-Relationship  Diagram  (ERD)  — 
and  multiple  supporting  matrix  diagrams.  The  OHD  simply 
diagrams  the  organizational  structure  of  the  enterprise.  The 
FHD  records  the  high-level  business  functions  (activities) 
performed  by  the  enterprise,  i.e.,  provides  the  activity 
component  of  the  business  model;  the  FDD  records  the 
dependencies  between  these  business  activities.  The  ERD, 
which  is  actually  part  of  a  Subject  Area  Diagram  (SAD), 
graphically  displays  the  data  required  to  perform  the 
activities,  i.e.,  provides  the  data  component  of  the  business 
model.  (The  Subject  Areas  are  the  activities  in  which  a 
business  is  interested.)  Matrices  provide  mechanisms  for 
recording  business  related  information,  such  as  goals, 
objectives,  strategies,  critical  success  factors,  etc. 

The  ISP  analysis  includes  the  following  procedural  steps: 

1.  Collect  and  evaluate  existing  strategic  plans 

2 .  Create  an  overview  model  of  the  enterprise 

3.  Conduct  business-oriented  strategic  analyses 

4.  Create  a  top-level  analysis  of  corporate  data 
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5.  Refine  the  enterprise  model  and  entity-relationship 
diagram 

6.  Group  the  enterprise  model  into  natural  clusters 

7.  Analyze  current  systems  to  determine  what  changes  are 
needed 

8.  Prioritize  the  business  areas  for  Business  Area  Analysis 
Each  procedural  step  actually  consists  of  several  individual 
tasks,  and  provides  an  outline  for  reporting  the  results  of 
the  analysis.^ 

a.  Evaluate  Strategic  Plans 

Types  of  strategic  plans  include  existing 
strategic  business  plans,  existing  Information  Strategy 
Planning  plans,  existing  strategic  information  technology 
plans,  existing  critical  success  factor  studies,  top 
management  goals  and  objectives,  existing  data  models,  and  any 
other  existing  relevant  plans  or  system  architecture 
documents.  Strategic  plans  generally  contain  one  of  four 
planning  components: 

Mission.  The  mission  of  an  enterprise  is  the  highest- 
level  statement  of  objectives.  It  gives  a  broad 
description  of  the  purpose  and  policy  of  the  enterprise. 

Objectives.  Objectives  are  general  statements  about  the 
directions  in  which  a  firm  intends  to  go,  without  stating 
specific  targets  to  be  reached  by  particular  times. 


^  A  full  outline  of  a  suggested  procedural  steps  for 
Information  Strategy  Planning  is  in  James  Martin's  INFORMATION 
ENGINEERING  Book  II:  Planning  and  Analysis  (Prentice  Hall, 
1990) 
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Goals.  Goals  are  specific  targets  that  are  intended  to  be 
reached  by  a  given  time.  A  goal  is  thus  an  operational 
transform  of  one  or  more  objectives. 

Strategy.  A  strategy  in  an  enterprise  is  a  pattern  of 
goals,  policies,  and  plans  that  specify  how  an 
organization  should  function  over  a  given  period.  A 
strategy  may  define  areas  for  product  development, 
techniques  for  responding  to  competition,  means  of 
financing,  size  of  the  organization,  image  the  enterprise 
will  project,  and  so  on.  (Martin,  1990b,  p.  70) 

Additionally,  different  goals  can  have  different  timeframes 

associated  with  them,  otherwise  known  as  "planning  horizons." 

Strategic  goals  generally  relate  to  long-term  planning  of  five 

years  or  more.  Tactical  goals  generally  relate  to  short-term 

planning  of  about  one  year  or  less. 

As  previously  discussed,  the  Naval  Postgraduate 
School's  expanded  mission  statement  best  summarizes  the 
overall  objectives  for  the  enterprise,  and  is  repeated  here: 

The  Naval  Postgraduate  School  exists  for  the  sole 
purpose  of  increasing  the  combat  effectiveness  of  the  Navy 
and  Marine  Corps.  It  accomplishes  this  by  providing  post¬ 
baccalaureate  degree  and  nondegree  programs  in  a  variety 
of  subspecialty  areas  not  available  through  other 
educational  institutions.  NPS  also  supports  the 
Department  of  the  Navy  through  the  continuing  programs  of 
naval  and  maritime  research  and  through  the  maintenance  of 
an  expert  faculty  capable  of  working  in,  or  as  advisors 
to,  operational  commands,  laboratories,  systems  commands, 
and  headquarters  activities  of  the  Navy  and  Marine  Corps. 
(NPS,  1994)  ^ 

In  order  to  accomplish  this  mission,  NPS  has 
approved  a  strategic  vision  for  the  future,  known  as  the  NPS 
Vision  2000.  Figure  IV. 2  describes  the  vision  statement.  A 
set  of  Guiding  Principles,  developed  by  the  NPS  Executive 
Steering  Committee,  supports  the  organization's  move  toward 
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It  is  NFS's  vision  to  be  recognized  as  the  graduate  school  of  choice  for  defense  establishment 
students  and  as  a  premier  research  university  at  home  and  abroad. 

a.  Our  students  will  find  the  school  academically  challenging  and  their  ctirricula  unique.  We 
will  ensure  a  maximum  value-added  learning  environment  for  each  student. 

b.  Our  programs  will  continue  to  grow  to  met  the  emerging  specific  needs  of  all  services,  DoD 
and  the  government  as  consistent  with  our  mission.  The  breadth  of  sponsorship  for  these  curricula 
will  continue  to  grow. 

c.  The  highest  quality  of  instruction  will  remain  a  paramount  objective. 

d.  Students  will  view  NFS  as  a  valuable  step  in  their  preparation  for  joint  and  combined  service. 

e.  Our  research  will  condnue  to  be  recognized  throughout  the  government  as  providing  valuable, 
responsive  and  cost  effective  products,  relevant  to  current  and  future  defense  applications.  We  will 
remain  on  the  leading  edge  of  technology,  management  and  warfighting  improvements. 

f.  Our  student  theses  will  be  valued  throughout  DoD  as  thought  provoking,  program-enhancing, 
and  contributing  to  the  solving  of  DoD  problems. 

g.  Our  faculQ'  will  be  even  more  sought  after  as  participants  in  the  most  prestigious  national  and 
international  research  activities,  and  for  hi^  level  DoD  positions  and  consultations. 

h.  NFS  postgraduate  education  will  continue  to  stand  out  as  a  key  element  in  tire  career  of 
military  ofticers  and  will  enhance  their  warfighting  capability  and  professional  development. 

i.  NFS  will  be  a  nationally  recognized  leader  in  applying  TQL  to  tire  university  environment  and 
in  both  recognizing  and  encouragmg  the  contributions  and  development  of  all  its  employees.  (NFS, 


Figure  IV. 2  Naval  Postgraduate  School  Vision  2000 

the  vision.  Figure  IV. 3  provides  these  guiding  principles. 
Together,  the  NFS  Vision  2000  and  the  Guiding  Principles 
provide  a  top-level  list  of  objectives. 

In  addition  to  the  overall  NPS  strategic  vision, 
other  sources  of  objectives  exist.  For  example,  the  NPS 
Computer  Advisory  Board  (CAB)  proposes  an  Information  Systems 
Vision  Statement.  The  draft  proposal  contains  three 


j  We  deal  infli  each  otfaer  — customeK,  co-wort*rs  and  the  comnninity- with  integrity  aad  respect;  OUT  doore  are 

9P^:h>::?nen  and;  women  alike  without  regard  to  race,  color^  religion,  handicap,  or  national  origins 

l^t  and  sensible  jnc^ement,  not  micro-management,  guide  people's  actions.  We  believe  that  everyone  is  capable 
dayTto-day  performance.  Everyone  makes  decisions  based  on  the  best  available  information  and  considers  the 
*h?>apt  on  those  affect^.  We  trust  one  another  to  behave  and  make  decimns  consistent  with  our  values,  policies  and 
guidelines,  without  reliance  on  the  choking  rules  of  micro-management. 

:  AU  snccesses,  however  small,  deserve  immediate  recognition.  We  care  for  each  other  ^st  as  we  care  for  our 
customers.  The  innovation,  creativity  and  expertise  of  our  fecultv.  staff  and  students  «re  valued  and  rewarded  W*  bAtd 


Encouraging  risk  takiug  and  tolerating  faOnre  are  a  must  if  we  are  to  be  innovative.  AH  hands 
ont.lhe.ways  they  limit  or  deceive  themselves  and  others.  We  eitcourage  everyone  to  tiy  new  ways:- 
constantly  tell  each  other  that  it’s  okay  to  make  nustakes  if  we  can  learn  ftom  them. 


:  „  »«inanu.raac  su  ucrures  ana  proceoures  are  the  enemy:  Eveiyoneregulaily  challenges  theories  of  why  things  are  the 
Reducing  and  simplifying  paperwork  and  eliminadrig  unnecessary  procedures  are  constant  top  inanagetheht 

agendas.  - 

dev^pmentshould  lea<^  notlag,  projected  growth.  Investments  in  training,  technology^  and  facilities 
jn  ^yMco  ofe;q)ected  program  growth  are  made  when  financially  posrible.  Facul^  and  staff  ate  constantly  encouraged  to 
::lmprove  their  leadership  skills  and  technical  con^eoce  through  traimng  and  education. 


Figure  IV. 3  Naval  Postgraduate  School  Guiding  Principles 


components:  a  draft  vision  statement,  a  proposed 

implementation  strategy,  and  preliminary  implementation  goals. 
Figures  IV.  4,  IV.  5,  and  IV.  6  provide  a  summary  of  the  key 
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points  in  each  section  of  the  draft  NPS  Information  Systems 
Vision  statement.  The  CAB  also  proposes  a  draft  set  of 
Principles  for  NPS  Information  Resource  Management,  based  on 
the  DoD's  Principles  for  Information  Management  found  in  DoD 
Directive  8000.1(D).  Figure  IV. 7  presents  these  proposed 
principles . 

Jb.  Create  an  Overview  Model 

As  previously  mentioned.  Figure  IV. 1  provides  a 
chart  of  the  organizational  structure.  Tab  A  of  Appendix  D 
provides  the  version  of  this  organizational  chart  that  was 
entered  into  IFF™  as  the  Organizational  Hierarchy  Diagram 
(OHD) .  The  organizational  chart  in  Figure  IV.  1  provides 
greater  accuracy  with  respect  to  the  lines  of  authority  due  to 
limitations  in  the  lEF™  OHD  diagramming  tool,  which  prevents 
multiple  lines  of  authority  to  exist  in  an  organizational 
diagram. 

An  overview  model  also  includes  a  high-level 
description  of  the  functional  hierarchy.  Generally,  a 
functional  hierarchy  consists  of  functions  at  the  top  level 
(Information  Strategy  Planning),  processes  at  the  second  level 
(Business  Area  Analysis)  ,  and  procedures  at  the  third  level 
(Business  System  Design)  of  the  information  engineering 
pyramid.  Functions  generally  consist  of  a  group  of  activities 
that  together  support  one  aspect  of  the  enterprise  mission; 
functions  are  ongoing  and  continuous,  not  based  on 
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NAVAL  POSTGRADUATE  SCHOOL  INFORMATION  SYSTEMS  VISION  STATEMENT 


1 .  We  envision  NPS  as  an  integrated  organization  well-positioned  to  fulfill  its  mission  and  meet  the 
needs  pf:  the  campus  community.  In  this  vision,  the  computing  and  information  resources  of  the 
campuS:  will  he  integrated  in  such  a  way  as  to  maximize  accessibility  and  ease  of  use.  AU  of  these 
tesources  of  the  campus  should  be  available  to  those  who  have  a  need  for  them.  This  vision  must 
;encompass  the  following  elements,  which  cover  the  primarv  functions  of  the  School:  - 


fastmction:  Promote  excellence  in  the  teaching  process  by  use  of  computer  assets  in 
and  out  of  the  classroom; 


Research:  promote  excellence  in  research  by  providing  the  most  advanced 
computational  systems  and  other  resources  possible  in  support  of  faculty  and  student 
research; 


Administration:  Support  efficient  administrative  procedures  for  students^  faculty;  and 
staff; 


libraiy  and  Computer  Center  Provide  computational  resources  and  computer-based 
:  information  services  and  serve  as  an  electronic  gateway  to  information  resources  on^ 
and  off-campus. 

2.  We  envision  that  the  School  will  provide  students,  faculty,  and  staff  with  ready  access  to  and  use 
of  modem  information  resources. 


3.  We  envision  that  the  School  will  provide  a  robust  secure  computing  capability  for  classified 
work. 


4,  We  envision  that  the  major  costs  for  a  baseline  level  of  computing  suj>port  will  be  included  as 
:p4rt  pf  the  normal  NPS  investment  and  operating  costs.  This  includes  costs  for  administrative  and 
student  access,  as  well  as  systems  necessary  for  faculty  instruction  and  research. 

5,  We  envision  that  the  computer  architecture  at  NPS  will  be  that  of  fully -distributed  systems,  which 
are  interconnected  to  maximize  shared  utilization  of  campus  resources,  effective  centralized 
hardware  and;  softvvare  support  for  these  systems  will  be  provided. 


DRAFT  DRAFT  DRAFT  DRAFT  DRAFT 


Figure  IV.  4  NPS  Information  Systems  Vision  Statement 
(NPS-CAB,  1993) 


organizational  structures,  and  categorize  what  is  done,  not 
how.  On  the  other  hand,  processes  are  specified  enterprise 
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NPS  IS  Vision  Implementing  Strateg} 

1.  The  Dean  of  Computer  and  Information  Services  (Code  05)  will  coordinate  the  information 
s\  siems  and  resources  on  the  campus. 

2  The  Dean  of  Computer  and  Information  Services  will  establish  and  maintain  a  long-range  plan 
for  campus  computing  and  information  resources 

3  The  long-range  plan  will  be  prepared  with  the  advice  of  the  Computer  Advisory  Board  (CAB) 

4.  The  planning  process  will  involve  consultations  with  all  the  end-users 

5.  The  Information  Resources  Management  Executive  Board  (IRMEB)  will  approve  the  Life  Cycle 
Management  Plan,  and  will  have  the  decision-making  power  and  authority  to  allocate  resources, 

6.  NPS  will  actively  recruit  qualified  information  resource  support  personnel,  and  support  their 
continued  development  and  growth  of  their  technical  expertise. 

7.  Instruction  will  be  supported  by  the  provision  of  computing  and  multi-media  assets  in  classrooms 
and  laboratories  as  appropriate. 

8.  Research  computmg  will  be  supported  at  the  most  modem  possible  level, 

9.  The  administrative  stiategj-  for  NPS  is  to  develop  an  integrated  sj’stem  designed  to  minimize 
duplicative  efforts 

10  NPS  will  develop  an  appropriate  centralized  computing  si^port  system  to  provide  baseline 
assistance  to  end-users 

DRAFT  DRAFT  DRAFT  DRAFT  DRAFT 


Figure  IV. 5  NPS  IS  Vision  Implementation  Strategy 
(NPS-CAB,  1993) 

activities  that  are  executed  repeatedly;  processes  can  be 
described  in  terms  of  inputs  and  outputs,  have  definable 
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NP$  IS  Vision  Implementation  «-  Initial  Goals 

:l  .vEach  curriculum  review;froni  1994  through  1996  will  evaluate  NFS’s  progress  toward  providing 
students  opportunities  to  acquired  computer  and  information  resources  skills  to  meet  their 
professional  career  requirements. 

2::  iBy iOctober  1994,  every^  faculty  and  staff  member  will  have  access  from-  their  desktop  to 
networked  computing  resources  sufficient  for  their  needs. 

;  3,::Each:  faculty  and;  staff  member  wOl  have  access  to  a  campus-wide  electronic  mail  system  by 
October  1994. 

4,:  iGampus  network  bandwidth  will  continue  to  improve  until  a  bandwidth  of  100  Mbps  is  available 
to  the  desktop  by  October  1995, 

SiiiThe .School  will  provide  access  to  worldwide  networks  of  current  importance. 

6.  ;Scientific  visualization  facilities  will  be  maintained  that  are  capable  of  displaying  and  interpreting 
the  large  volume  of  results  generated  by  large-scale  simulations  and  models. 

7.  NFS  will  develop  support  for  multi-media  applications. 

8.  Electronic  document  interchange  will  replace  routine  paper  transactions. 

9.  Site  licenses  will  be  obtained  for  the  software  packages  commonly  used  on  campus 

lO.iThe  Eibraiy  will  develop  an  on-line  catalog  as  a  campus-wide  information  resource  accessible 
of  the  network  by  October  1994. 

1 1.  The  Library  and  Computer  Center  wifi  implement  a  Campus  Wide  Information  System  (GWIS) 
by  October  1994. 

DRAFT  DRAFT  DRAFT  DRAFT  DRAFT 


Figure  IV. 6  NFS  IS  Implementation  Goals 


(NPS-CAB,  1993) 
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Principles  for  NPS  Information  Resource  Management 


1  Simplifting  business  practices  through  eliramatjon  and  integration  takes  precedence  over 
automation,  whether  developing  new  or  enhancing  existing  information  sjstcms. 

2.  Before  information  systems  are  developed,  a  plan  and  a  business  case  must  first  be  prepared, 
business  methods  must  be  documented  with  process  models  and  validated  before  being  automateck 

3.  Priority  will  be  given  to  developing  and  enhancing  IS  that  contributes  directly  to  corporate 
business  strategies  and  effectiveness.  Data  processing  and  communications  efficiency  will  not  be 
the  prime  deterrent 

4.  NPS  users  are  responsible  for  the  success  of  their  information  systems  and  accountable  for  the 
accuracy  of  their  data  and  the  cost  of  IS.  That  requires  that  the  development  of  each  data  model, 
process  model,  and  information  system  he  led  by  a  functional  project  manager,  once  developed, 
each  model  and  system  should  be  operated  and  continuously  improved  functional  manager 
stewardship. 

5  Common  information  systems  will  be  deployed  among  all  operating  groups  unless  specific 
analysis  establishes  that  they  should  be  unique. 

6.  NPS  and  Naw  data  standards  must  be  followed. 

7.  Data  will  be  entered  only  once. 

5.  Data  will  be  accessible  to  alt  authorized  users,  while  being  safeguarded  from  unintentional  or 
unauthonzed  alteration,  destruction,  and  disclosure.  All  data  maintained  by  parts  of  the  NPS 
organization  arc  considered  to  be  "corporate  data".  That  is,  available  to  am  within  the  organization 
who  required  it,  Responsibilitj’  for  back*up,  accuracy,  entiy,  use,  etc  will  be  assigned  to 
organizational  entities,  but  the  data  is  owned  by  the  larger  corporate  base. 

9,  The  architecture  of  the  computing  and  communications  infrastructure  will  be  transparent  to  the 
information  systems  that  rely  on  it 

10,  Life  Cycle  Management  and  Security  Management  will  be  m  accordance  with  (lAW)  established 
DoD  and  DoN  directives 

1 1 ,  Implementation  of  software  solutions  will  maximize  use  of  off-the-shelf  rather  than  umquely 
designed  in  house  or  contracted 

DRAFT  DRAFT  DRAFT  DRAFT  DRAFT 


Figure  IV. 7  Draft  Principles  for  NPS  IRM 


(NPS-CAB,  1993) 
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beginning  and  ending  points,  and  like  functions,  are  not  based 
on  organization  structures,  and  identify  what  is  done,  not 
how. 

The  two  major  business  functions  of  the  Naval 
Postgraduate  School  are  education  and  research.  However,  in 
order  to  provide  a  complete  model  of  the  NPS  enterprise,  the 
NPS  functions  performed  in  support  for  the  Superintendent's 
collateral  duties  must  also  be  included.  Therefore,  the 
Superintendent-specific  duties  (such  as  Navy  academic 
coordinator  and  Naval  Subarea  Six  coordinator)  combine  with 
the  NPS-specific  business  functions  in  the  analysis.  A 
bottom-up  analysis  of  the  functions  performed  at  NPS  provides 
the  basis  for  the  activity  model.  The  primary  reference 
sources  are  the  NPS  Standard  Organization  and  Regulations 
Manual  (SORM) ,  NAVPGSCOLINST  5400. 2C  (22  August  1990),  and  a 
draft  of  the  next  SOHM  revision,  NAVPGSCOLINST  5400. 2D;  these 
are  supplemented  by  interviews  with  selected  senior  and  middle 
management  personnel.  Aggregation  of  the  results  provides  a 
top-level  overview  of  the  functional  areas  at  NPS.  Thus,  the 
highest-level  of  the  function  or  activity  model  contains  the 
following  three  functional  areas,  shown  in  Figure  IV.  8: 
Coordinate  Academic  Programs,  Coordinate  Subarea  Six,  and 
Perform  All  Assigned  Duties. 

For  purposes  of  this  analysis,  the  primary 
interest  lies  in  the  Coordinate  Academic  Programs  functional 
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area.  Coordinate  Academic  Programs  decomposes  to  provide  the 
high-level  functions  shown  in  Figure  IV. 9.  Tab  B  of  Appendix 
D  provides  a  description  of  each  of  these  top-level  functions. 

One  noted  analytical  deficiency  is  that  this  high- 
level  functional  model  does  not  follow  the  DoD  Enterprise 
Activity  Model  format.  The  reason  for  this  discrepancy  is 
straight-forward:  the  list  of  functions  performed  at  NPS 
derive  from  a  bottom-up  analysis  vice  a  top-down  analysis,  and 
this  project  makes  no  attempt  to  integrate  the  two  analysis 
methods.  Additionally,  the  unique  nature  of  the  Naval 
Postgraduate  School  as  both  a  military  and  an  academic 
organization,  and  the  specialized  business  functions  that 
result  from  this  combination,  prevents  neat  casting  of  the  NPS 
business  functions  into  the  DoD  Enterprise  Activity  Model 
functional  categories.  In  order  to  fully  conform  to  DoD 


85 


NAVAL  POSTGRADUATE  SCHOOL  ACTIVITY  MODEL 
ACTIVITY  HIERARCHY 


SUPERINTEND  NPS 


COORDINATE  ACADEMIC  PROGRAMS 


ADMINISTER  EDUCATION  PROGRAMS 


ADMINISTER  FULLY-FUNDED  PROGRAMS 


EXERCISE  BUDGETARY  CONTROL 
MANAGE  ALL  PROGRAM  CURRICULA 
ADMINISTER  NPS  PROGRAMS 


MANAGE  ALL  NPS  RESOURCES 
ADMINISTER  NPS  ACADEMIC  PROGRAMS 
ADMINISTER  NPS  OFFICER  STUDENTS 
PROVIDE  NPS  NON-ACADEMIC  SUPPORT 
ADMI NISTER  NPS  RESEARCH  PROGRAM 
ADMINISTER  AVIATION  SAFETY  PROGRAM 
DIRECT  DRMI 


ADMINISTER  OTHER  USN  SCHOOL  PROGRAMS 
ADMINISTER  aVILIAN  INSTRUCTION  PROGRAMS 


ADMINISTER  CONTINUING  EDUCATION  PROGRAMS 
CONDUCT  OTHER  INSTRUCTION  AS  DIRECTED 


PROVIDE  INSTRUCTION  TO  STUDENTS 
KEEP  CNO  ADVISED 


COORDINATE  SUBAREA  SIX 
PERFORM  ALL  ASSIGNED  DUTIES 


policy,  the  NPS  functions  should  be  assigned  to  the  closest 
corresponding  functional  areas  and  functional  activities 
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specified  in  the  DoD  Enterprise  Activity  Model.  This 
integration  task  is  left  for  future  analytical  endeavors. 

A  Function/Organization  Unit  matrix,  Tab  C  of 
Appendix  D,  records  the  involvement  of  each  organizational 
unit  with  a  specific  function.  A  limitation  of  the  lEF™ 
restricts  the  use  of  functions  in  matrices  to  the  elementary 
(lowest  level  in  any  hierarchy)  functions;  therefore,  several 
of  the  functions  shown  in  Figure  IV.  9  are  absent  from  the 
Function/Organization  Unit  matrix.  This  is  an  unfortunate 
result  of  an  artificiality  of  this  analysis.  This  analysis 
combines  elements  of  the  BAA  phase  (function  decomposition) 
with  the  elements  of  the  ISP  phase  (function  definition)  in 
order  to  achieve  sufficient  detail  to  provide  an  opportunity 
for  analysis  of  the  information  architecture  model.  System 
analysts  generally  avoid  this  problem  by  only  specifying  one 
level  of  functions  within  each  functional  area  in  the  ISP 
phase,  not  multiple  levels  as  in  Figure  IV. 9. 

The  analysis  of  the  involvement  of  Organizational 
Units  with  Functions  in  the  matrix  uses  the  following  codes: 
9:  Executive  or  policy-making  AUTHORITY 
8:  Direct  management  RESPONSIBILITY 
7:  Technical  EXPERTISE 
6:  Actual  execution  of  the  WORK 
X:  INVOLVED  in  the  function 
This  matrix  is  further  discussed  in  a  later  section. 
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c.  Conduct  Business-OrientBd  Strategic  Analyses 

Four  types  of  business-oriented  strategic  analyses 
provide  additional  supporting  data.  Analysts  often  perform 
these  analyses  in  parallel  with  the  other  analyses  within  the 
Information  Strategy  Planning  stage. 

(1)  Conduct  Analysis  of  Goals  and  Problems.  The 
earlier  section  on  strategic  planning  discusses  several 
documents  which  describe  the  high-level  objectives  of  the 
command.  Unfortunately,  none  of  the  more  commonly  found 
strategic  planning  documents  identified  —  with  the  exception 
of  the  NPS  mission,  NPS  Vision  2000,  and  Guiding  Principles  — 
exist.  Numerous  efforts  are  underway  to  develop  long-range 
strategic  plans  under  the  leadership  of  the  NPS  Executive 
Steering  Committee,  but  they  have  not  yet  reached  fruition. 

(2)  Conduct  Critical  Success  Factor  Analysis. 
Critical  Success  Factors  (CSF)  are  factors  that  have  a  major 
influence,  positive  or  negative,  on  the  attainment  of  an 
enterprise  objective  or  goal.  Another  way  to  look  at  CSFs  is 
"Goals  are  ends;  CSFs  are  means  to  those  ends."  (Martin, 
1990b,  p.  89)  Normally,  written  documentation  throughout  the 
enterprise  identifies  and  defines  the  CSFs.  When 
documentation  does  not  exist,  the  other  principal  method  for 
determining  CSFs  are  analyst  interviews  of  senior  management 
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personnel.  The  CSF  analysis  generally  creates  and  documents 
a  list  of  critical  information,  a  set  of  critical  assiimptions, 
and  a  set  of  critical  decisions. 

No  specific  documentation  exists  that 
identifies  the  CSFs  for  NFS.  The  Executive  Steering  Committee 
identifies  a  number  of  strategic  issues  witihin  six  different 
business  areas  —  Curriculum/DoD  Students,  New  Markets, 
Budget,  Faculty,  Sponsors,  and  Other  —  and  a  new  set  of 
philosophical  guidelines  to  complement  the  NFS  mission,  Vison 
2000,  and  Guiding  Frinciples  (NFS,  August  23,  1994) .  However, 
using  the  previous  definitions  for  mission,  strategy, 
objectives,  goals,  and  CSFs,  these  strategic  issues  are  not 
really  CSFs;  they  are  objectives,  interspersed  with  one  or  two 
goals . 

Interviews  with  senior  and  middle  management 
personnel  at  NFS  reveal  that  one  recurring  critical  success 
factor  is  information:  the  need  to  have  the  right  information 
at  the  right  time,  in  the  right  format. 

(3)  Conduct  Technology  Impact  Analysis.  This 
subtask  provides  a  determination  of  the  potential  impact  of 
information  technology  on  the  enterprise,  and  generally 
consists  of  a  literature  search  for  emerging  information 
technologies  and  applications.  Chapter  V  discusses  the 
results  of  the  technology  review. 
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(4)  Conduct  Strategic  Information  Systems  Study. 
Strategic  information  systems  are  the  mission-critical  systems 
which  directly  enable  an  organization  to  accomplish  a  mission. 
Therefore  a  strategic  information  systems  study  addresses  the 
ways  in  which  information  systems  can  enhance  an 
organization's  operations.  Although  this  analysis  did  not 
conduct  a  strategic  systems  study,  the  proposed  NPS 
Information  System  Vision  and  its  implementing  strategies  and 
goals  provides  an  excellent  starting  point. 

d.  Create  a  Top-Level  Corporate  Data  Model 

The  highest-level  view  of  the  data  model  has  only 
two  Subject  Areas:  the  Naval  Postgraduate  School  and  Other 
Organizations.  Decomposing  the  Naval  Postgraduate  School 
subject  area,  the  top-level  view  of  the  model  consists  of 
thirteen  subject  areas;  some  of  these  subject  areas  are  even 
further  subdivided,  containing  additional  subject  areas. 
Figure  IV. 10  shows  the  thirteen  primary  subject  areas;  Figure 
IV.  11  shows  the  expanded  diagram  including  all  subject  areas. 

Unlike  the  activity  model,  the  thirteen  primary 
subject  areas  for  the  NPS  data  model  directly  correlate  to  the 
top-level  entity  types  in  the  DoD  Enterprise  Data  Model  (DoD, 
1993) .  Although  the  data  model  analysis  also  is  a  bottom-up 
analysis,  the  number  and  classes  of  data  entity  types  supports 
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Figure  IV.  10  NPS  Data  Model  Subject  Areas  —  Top  Level 


easier  integration  with  the  DoD  Enterprise  Data  Model.  In 
this  manner,  the  NPS  data  model  meets  DoD  guidance  for  use  of 
the  DoD  Enterprise  Model. 

Each  subject  area  contains  its  associated  entity 
types;  the  top-level  Entity-Relationship  Diagram  (ERD) 
contains  fourteen  entity  types.  At  the  next  level  of  detail 
used  in  the  analysis,  the  ERD  contains  61  entity  types,  listed 
in  Figure  IV. 12.  Additionally,  some  of  the  entity  types  at 
this  level  have  entity  subtypes.  Tab  D  of  Appendix  D  contains 
a  listing  of  all  the  subject  areas,  entity  types,  entity 
subtypes,  and  the  relationships  between  entity  types.  Figure 
IV. 13,  although  difficult  to  view,  graphically  depicts  these 
objects,  and  represents  the  extent  of  the  level  of  detail  used 
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for  this  analysis.  Tab  E  of  Appendix  D  contains  a  viewable 
full  size  foldout  of  the  diagram. 

A  Function/Data  Entity  Type  matrix  describes  the 
involvement  of  each  data  entity  type  with  each  function.  Tab 
F  of  Appendix  D  provides  the  Function/Data  Entity  matrix. 
Since  the  lEF™  tool  only  diagrams  entity  types,  not  subtypes, 
the  matrix  does  not  include  all  the  entity  subtypes  depicted 
in  Figures  IV.  13  and  Tab  D.  The  expansion  from  fourteen 
entity  types  to  59  entity  types  is  an  artificiality  of  the 
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Figure  IV. 11  NPS  Data  Model  Subject  Area  Decomposition 
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Figure  IV. 12  NPS  Data 

Model  Data  Entity 

Types  —  Top  Level 

analysis  to  overcome  the  limitations  of  the  automated  tool  in 
the  ISP  phase  —  the  59  entities  actually  include  all  the 
entity  subtypes  of  the  original  fourteen  entity  types. 

The  matrix  uses  the  following  codes,  arranged  in 
order  of  precedence: 

C:  Create 
D:  Delete 
U :  Update 
R:  Read 
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The  Create  relationship  implies  the  ability  to  Delete,  Update, 
or  Read;  the  Delete  relationship  implies  the  ability  to  Update 
or  Read;  and  the  Update  relationship  implies  the  ability  to 
Read.  The  codes  apply  to  the  creation,  deletion,  update,  and 
read  of  specific  data  instances  of  each  data  entity  type,  not 
to  the  object  itself.  For  example,  the  Admissions  Office  does 
not  "create"  a  Student,  but  the  office  does  create  an  instance 
in  a  database  of  a  Student  when  one  is  admitted  to  the  school. 

The  matrix  includes  a  number  of  blank  columns, 
which  correspond  to  "generic"  entity  types.  This  condition  is 
the  result  of  attempts  to  limit  the  level  of  detail  in  this 
phase  while  still  providing  enough  detail  to  perform  some 
analysis.  These  generic  entity  types  result  from  artificially 
promoting  the  entity  subtypes  and  not  redefining  the 
relationships  among  the  original  entities  as  relationships 
among  all  the  newly  promoted  entities.  For  example,  a  Person 
entity  type  has  four  subtypes  —  Faculty  Person,  Staff  Person, 
Student  Person,  and  Visitor  Person  —  but  the  relationships 
with  other  entity  types  are  at  the  Person  level.  Promoting 
these  entity  subtypes  technically  requires  re-establishing  the 
Person  relationships  at  the  Faculty,  Staff,  Student,  and 
Visitor  level;  this  level  of  detail  is  excessive  for  a  top- 
level  data  model  in  the  ISP  phase.  Therefore,  the  "generic" 
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entity  types  represent  the  original  entity  types  before  the 
promotion  of  subtypes,  and  provide  the  relationship  links  with 
other  entity  types. 

The  Data  Entity/Organization  Unit  Matrix,  Tab  G  of 
Appendix  D,  uses  the  same  CRUD  code  to  display  the 
relationship  between  each  data  entity  and  the  organizational 
units . 

e.  Refine  the  Enterprise  Model 

This  procedural  step  generally  provides  an 
opportunity  for  end-users  to  review  and  make  improvements  to 
the  enterprise  model.  The  potential  end-users  at  NFS  include 
representatives  from  every  major  organizational  unit.  Since 
insufficient  researcher  resources  prevents  any  attempt  to 
achieve  this  level  of  coordination  for  feedback  on  the 
enterprise  model,  an  academic  approach  using  selected  faculty 
members  as  technical  experts  provides  the  relevant  feedback 
and  refinement  iterations  for  this  analysis. 

f.  Perform  Cluster  Analysis 

The  Function/Entity  Type  Matrix  in  Tab  H  of 
Appendix  D  shows  the  results  of  using  IEF™'s  clustering 
algorithm  on  the  Create  relationships  in  the  matrix  in  an 
attempt  to  determine  natural  system  boundaries .  The  groupings 
" .  .  .  represent  logical  information  subsytem  groupings  with 
responsibility  for  creating  and  maintaining  the  various 
classes  of  data"  (Martin,  1990b,  p.  174)  .  Further  analysis  of 
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the  clustered  matrix  assigns  the  functions  which  remain 
outside  of  the  defined  groupings  to  a  particular  cluster  to 
complete  the  business  area  boundary  definition.  As  a  result 
of  this  analysis,  the  clustered  matrix  defines  eight  business 
areas.  Figure  IV. 14  defines  these  business  areas,  and  shows 
which  of  the  elemental  top-level  functions  (from  Figure  IV. 9) 
are  assigned  to  each  area.  The  overlapping  ranges  of  entity 
types  created  by  different  functions  indicates  some  functions 
are  grouped  incorrectly  within  a  functional  area.  However,  at 
this  top  level  in  the  model  the  functions  are  too  aggregated 
to  determine  which  functions  should  be  relocated;  further 
decomposition  of  the  functional  hierarchy  would  allow  better 
analysis.  The  naming  convention  for  the  business  areas 
generally  is  arbitrary,  but  follows  along  the  lines  of  the 
top-level  functional  areas.  The  business  areas  designated  in 
this  phase  are  the  basis  for  further  analysis  in  the  BAA 
phase. 

Some  organizations  also  perform  a  function 
dependency  analysis  during  this  portion  of  the  ISP  phase, 
resulting  in  a  Functional  Dependency  Diagram  (FDD) ;  however, 
most  organizations  defer  this  analysis  to  the  BAA  phase,  due 
to  the  high-level  overview  nature  of  the  ISP  phase.  This 
particular  analysis  effort  forgoes  the  function  dependency 
analysis  entirely. 
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Figure  IV. 14  Business  Areas  and  Functions 


g-  Analyze  Current  Information  Systems 

This  procedural  step  defines  the  existing 
information  systems  within  the  organization,  and  documents  the 
relationships  among  these  systems  and  organizational  units. 
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entity  types,  and  business  functions.  The  analysis  uses 
matrices  for  each  pair-wise  comparison,  which  can  be  clustered 
to  help  define  business  areas.  Tabs  I,  J,  and  K  of  Appendix 
D  provide  these  matrices. 

Due  to  analyst  resource  constraints  and  the  high- 
level  overview  nature  of  the  analysis,  the  listing  of  the 
organization's  information  systems  is  not  comprehensive  or 
complete;  the  listing  is  only  a  representational  sample  of 
NFS's  information  systems.  Therefore,  the  matrices  are  not 
useful  for  further  analysis  until  all  the  systems  at  NFS  are 
identified  and  entered  into  the  list. 

h.  Prioritize  Business  Areas 

During  this  procedural  step,  analysts  typically 
prioritize  development  of  the  business  areas  by  ranking  each 
area  based  on  a  n\imber  of  factors:  return  on  investment, 

demand,  organizational  impact,  existing  systems,  likely 
success,  resources  required,  and  concurrent  implementations. 
Once  the  business  areas  are  prioritized,  system  development 
shifts  to  the  BAA  phase  for  each  business  area. 

This  project  does  not  include  any  analysis  for 
prioritizing  business  areas  for  system  development. 

2.  Business  Area  Analysis  (BAA) 

The  objectives  of  the  Business  Area  Analysis  are: 

1.  Fully  identify  and  define  the  type  of  data  required  by 
the  business. 
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2.  Identify  and  define  the  business  activities  that  make  up 
each  business  function. 

3.  Define  the  necessary  sequence  of  business  activities. 

4.  Bring  the  results  of  data  analysis  together  with  activity 
analysis  to  illustrate  how  changes  to  the  process 
definition  affect  data  analysis. 

5.  Provide  the  basic  information  necessary  to  define  data 
structures . 

6.  Provide  the  starting  point  for  transformation  to  Design 
and  the  definition  of  procedures.  (lEF™,  1991) 

In  short,  the  principal  objective  of  the  Business  Area 

Analysis  phase  is  to  refine  in  detail  a  specific  portion  of 

the  Information  Architecture  established  during  the 

Information  Strategy  Planning  stage.  Emphasis  is  on  the 

entity  types  and  functions  within  a  specific  Business  Area. 

The  deliverables  for  this  phase  consist  of  an  ERD,  a  Process 

Hierarchy  Diagram  (PHD) ,  and  a  Process  Action  Diagram  (PAD) . 

The  ERD  in  this  phase  is  simply  a  refinement  of  the 
ERD  from  the  ISP  stage  to  create  a  more  detailed  definition  of 
the  data  entity  types,  their  relationships,  and  other 
characteristics  (attributes) . 

The  PHD  is  likewise  a  refinement  of  the  FHD  from  the 
ISP  phase;  the  functions  decompose  into  processes  until  the 
elementary  processes  are  defined.  The  corollary  to  the 
function  dependencies  recorded  in  the  FDD  is  the  process 
dependencies  recorded  in  the  PDD. 

The  PAD  is  the  result  of  interaction  analysis  which 
details  how  processes  affect  data,  and  graphically  displays 
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the  inputs  into  an  elementary  process,  the  action  performed  by 
an  elementary  process,  and  the  output  resulting  from  the 
execution  of  an  elementary  process. 

BAA  establishes  what  data  and  what  processes  are 
required  to  operate  the  enterprise.  BAA  does  not  establish 
how  procedures  operate.  BAA  creates  models  (or  expands  models 
from  the  ISP  phase)  of  the  fundamental  data  and  processes 
which  are  necessary  for  the  organization,  independent  of 
technology,  independent  of  the  current  systems,  and 
independent  of  the  current  organizational  structure.  The 
procedural  steps  for  the  BAA  phase  are: 

1.  Create  a  preliminary  data  model 

2.  Create  a  preliminary  process  model 

3.  Successively  refine  the  information 

The  data  model  and  the  process  model  undergo  iterative 
refinements,  until  a  complete  representation  of  the  data,  the 
elementary  processes,  and  their  relationships  is  achieved.  An 
elementary  process  is  a  process  that  cannot  be  decomposed 
further  without  stating  how  a  procedure  is  carried  out. 
Examples  of  elementary  processes  are:  create  instance  of 
student,  update  instance  of  student,  and  delete  instance  of 
student . 

This  project  only  performs  selected  portions  of  the 
first  iteration  within  the  BAA  phase;  the  first  iteration 
applies  to  the  enterprise  as  a  whole,  not  to  any  particular 
business  area.  The  discussion  of  the  analysis  from  this  phase 


101 


consists  of  three  components:  the  data  model,  the  functional 
model,  and  the  relationship  model. 

a.  Data  Model  (Entity  Relationship  Diagram) 

Refinement  of  the  relational  data  model  includes 
adding  keys  and  other  attributes  to  each  data  entity  type, 
adding  intersection  entity  types  where  appropriate,  and 
ensuring  that  the  attribute  groupings  are  in  Fourth  Normal 
Form.®  This  project  provides  only  a  top-level  data  model,  and 
the  BAA  phase  does  not  significantly  refine  the  data  model 
beyond  the  ISP  phase.  Each  data  entity  type  acquires  one  or 
two  attributes;  these  attributes  are  an  identification  code 
that  serves  as  the  key,  and/or  a  classifying  attribute  that 
determines  an  entity  subtype.  Tab  L  of  Appendix  D  provides  a 
listing  of  each  entity  type,  entity  subtype,  and  their 
attributes . 

Jb.  Functional  Model  (Process  Hierarchy) 

Since  the  functional  model  was  created  through 
bottom-up  analysis  and  then  aggregated,  multiple  levels  of 
functional  decomposition  already  exist.  In  order  to  analyze 
the  functions  at  the  highest  level,  most  of  the  decomposed 
functions  were  coded  as  processes.  In  reality,  some  of  these 
activities  are  functions  and  some  are  processes.  (Recall  the 


®  Fourth  Normal  Form  is  loosely  defined  as  follows: 
"Every  data  item  (attribute)  in  a  record  is  dependent  on  the 
key,  the  whole  key,  and  nothing  but  the  key."  (Martin,  1990b, 
p.  236) 
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earlier  definitions  of  functions  and  processes .)  For  purposes 
of  this  analysis,  no  distinction  between  functions  and 
processes  is  made  for  the  first  (and  only)  iteration. 

Many  of  the  processes  in  the  decomposed  layers 
appear  to  coincide  with  the  levels  in  the  organizational 
structure  hierarchy.  The  aggregation  (or  decomposition)  of 
some  processes  does  follow  organizational  structure  lines,  but 
this  is  due  to  functional  grouping,  and  not  necessarily  due  to 
organizational  unit  grouping.  Further  evidence  of  this 
phenomenon  appears  in  the  description  of  some  activities, 
which  uses  an  organizational  position  to  describe  a  particular 
function.  An  example  of  this  type  of  description  is  an 
activity  that  is  listed  as  "Serve  as  primary  assistant  to 
...."  Further  decomposition  of  the  activity  model  removes 
these  types  of  discrepancies  by  specifying  the  elementary 
processes  involved  in  that  type  of  activity  or  function.  Tab 
M  of  Appendix  D  provides  the  first  iteration  graphical 
decomposition  of  the  activity  model;  Tab  N  of  Appendix  D 
provides  a  complete  listing  of  all  activities,  their 
descriptions,  and  their  subordination  to  other  activities. 

As  in  the  ISP  phase,  this  project  does  not  conduct 
any  process  dependency  analysis, 
c.  Relationship  Model 

Generally,  the  BAA  phase  includes  refinement  of 
all  existing  matrices,  and  the  creation  of  matrices  that 
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involve  processes  instead  of  functions.  Due  to  the  nature  of 
the  first  BAA  phase  iteration,  which  involves  an  enterprise¬ 
wide  vice  business  area  approach,  and  the  tremendously  large 
number  of  processes  defined,  this  project  does  not  attempt  to 
define  the  inter-relationships  between  processes  and  other 
objects . 

d.  Results  of  Analysis 

ISP  and  BAA  analyses  not  only  model  an  existing 
organization,  but  also  provide  a  mechanism  for  determining  if 
the  organization  should  be  changed,  and  if  so,  how.  In  this 
regard,  analysis  of  the  matrices  developed  for  this  project 
provide  some  limited  insight  for  suggesting  possible  changes 
to  the  organizational  structure.  Unfortunately,  the  high- 
level  nature  of  the  enterprise  model  analysis  significantly 
limits  the  ability  to  draw  extensive  conclusions  from  the 
results . 

C,  RECOMMENDATIONS  FOR  THE  COMMITTEE  ON  NFS  MISSION 

ORGANIZATION  STUDY 

The  timing  of  this  project  report  coincides  with  an  effort 
by  the  Provost/Academic  Dean  to  determine  whether  or  not 
structural  changes  are  required  for  the  NPS  organization.  The 
Committee  on  NPS  Mission  Organization  has  a  charter  and  a  list 
of  questions,  shown  in  Figure  IV.  15,  to  guide  their  effort. 

The  NPS  enterprise  model  analysis  suggests  answers  to  some 
of  these  questions  proposed  by  the  Provost.  The  analysis  and 
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LIST  OF  QUESTIONS  FOR  COMMITTEE  ON  NFS  MISSION  ORGANIZATION 


1 .  Does  the  Office  of  the  Dean  of  Faculty  have  too  much  administrative  oversight  for  a  single 
individual?  Should  NFS  return  to  Divisional  Deans?  If  so.  define  the  Divisions. 

2  Do  the  functions  of  the  Office  of  the  Dean  of  Faculty  overlap  too  strongly  the  functions  of  the 
Office  of  the  Dean  of  Instruction*?  Do  we  need  both  offices’’  How  do  we  define  the  functions’’ 

3.  Do  the  functions  of  the  Office  of  Dean  of  Students/Director  ofPrograms  overlap  too  much  those 
of  the  Dean  of  Instruction?  If  these  arc  to  be  retained,  how  should  one  divide  the  respective 

4.  Do  we  need  a  Dean  of  Research  or  is  an  Office  of  Research  Administration  adequate? 

5.  Should  the  concept  that  NFS  really  operates  a  matrix  organi7ation  be  expanded  or  more 
formalized,  this  suggests  that  07  and  08  develop  faculty  and  faculty  research  sources,  whereas  03 
and  06  support  cumcular,  instructional,  and  student  activities 

6  Is  the  combination  of  Computer  Services  and  Information  Seivices  appropriate?  Or  should  they 
be  ^lit  and  put  under  the  supervision  of  other  Deans  or  answer  directly  to  the  Frovost?  How  does 
one  divide  the  computing  responsibilities  betUi'een  this  organization  and  the  individual  Departments’? 

7.  Has  the  function  of  part-time  Associate  Deans  served  NFS  well  in  identifying  and  giving 
adnimistrative  experience  to  a  wider  group  of  young  faculty,  or  has  it  produced  too  much 
administration?  How  best  can  NFS  accomplish  these  functions? 

8.  The  position  of  Assistant  to  the  Provost  has  expanded  its  functions  over  time  to  include.  1)  a 
budget  office  for  faculty,  staff,  and  OPTAR  mission  budgeting;  2)  a  staff  administrative  office  to 
reduce  the  burdens  of  administering  the  staff  by  the  respective  Deans  and  Chairs;  3)  an  Office  of 
Institutional  Research  to  centralize  institutional  data,  its  collection,  and  its  organization.  Are  these 
appropriate?  What  changes  are  recommended'? 

9.  "Who  should  have  responsibilit}'  for  development  and  marketing  of  new  instructional  programs? 
new'  research  centers’?  new  instructional  laboratories'?  distance  leammg’?  the  international  programs? 

10  hi  recommending  changes,  seek  ways  to  reduce  the  adirunistrative  overhead  of  the  institution 


Figure  IV. 15  List  of  Questions  for  NPS  Mission  Organization 
(NPS-01,  August  16,  1994) 

recommendations  that  follow  address  their  respective  numbered 
questions  from  Figure  IV. 15; 

Question  #2.  The  functions  of  the  Dean  of  Faculty  overlap 
the  functions  of  the  Dean  of  Instruction,  particularly  in 


educational  program  planning,  conduct,  and  administration; 
faculty  selection,  orientation,  and  development;  appointment 
of  Academic  Associates;  supervision  of  Academic  Associates; 
and  curricular  reviews.  The  Function  vs.  Organizational  Unit 
Matrix  (Tab  C  of  Appendix  D)  shows  that  both  Deans  have 
"Direct  Management  Responsibility"  for  the  same  function  — 
Provide  Instruction  to  Students.  Review  of  the  Code  06  and 
Code  07  functions  in  the  Activity  Hierarchy  Decomposition 
(Tabs  M  and  N  of  Appendix  D)  provides  additional  examples  of 
this  functional  overlap.  Both  offices  conduct  functions  which 
are  unique  and  should  remain  distinctly  separate;  only  the 
overlapping  functions  should  be  divided  between  the  two 
offices.  The  Dean  of  Faculty  can  deal  with  personnel  issues, 
such  as  faculty  selection,  orientation  and  development  and  the 
appointment  and  supervision  of  Academic  Associates.  The  Dean 
of  Instruction  can  deal  with  academic  issues,  such  as 
educational  program  planning,  conduct  and  administration  and 
curricular  reviews. 

Question  #3.  The  functions  of  the  Dean  of  Instruction 
significantly  overlap  the  functions  of  the  Dean  of 
Students/Director  of  Programs,  especially  in  the  areas  of 
curricular  program  planning,  evaluation,  and  development; 
curricular  reviews;  and  military  faculty  selection, 
orientation,  and  development.  As  in  the  previous  question, 
the  Function  vs.  Organizational  Unit  Matrix  (Tab  C  of  Appendix 
D)  shows  a  significant  overlap  in  "Direct  Management 
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Responsibility"  between  Code  03  and  Code  07  in  almost  all 
functional  areas.  This  overlap  also  shows  up  in  the  Activity 
Hierarchy  Decomposition  (Tabs  M  and  N  of  Appendix  D)  .  The 
Dean  of  Students/Director  of  Programs  currently  serves  as  the 
coordinator  for  the  military  aspects  of  each  curricular 
program,  such  as  the  military  educational  requirements  (MER) . 
This  function  goes  better  with  the  Office  of  the  Dean  of 
Instruction,  who  coordinates  the  academic  aspects  of  each 
curricular  program.  Curricular  reviews  and  faculty  selection 
also  go  better  with  the  Dean  of  Instruction. 

Question  #4.  Due  to  the  importance  research  plays  in  the 
accomplishment  of  the  NPS  mission,  a  Dean  of  Research  is 
appropriate.  A  Dean  of  Research  serves  as  the  single  focal 
point  for  this  important  function;  his  duties  and 
responsibilities  go  far  beyond  simply  supervising  the 
administration  of  the  paperwork.  The  Function  vs. 
Organizational  Unit  Matrix  (Tab  C  of  Appendix  D)  and  the 
Activity  Hierarchy  Diagram  Decomposition  (Tabs  M  and  N  of 
Appendix  D)  show  the  extent  of  the  Dean's  duties  and 
responsibilities . 

Question  #5.  As  discussed  in  the  previous  paragraphs,  the 
overlapping  responsibility  for  functions  in  the  matrix 
organization  at  NPS  hinders  effectiveness  and  efficiency. 
When  the  Dean  of  Faculty  concentrates  on  faculty  members,  the 
Dean  of  Research  concentrates  on  research,  the  Dean  of 
Instruction  concentrates  on  curricula  instruction,  and  the 
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Dean  of  Students  concentrates  on  military  student 
administration,  the  effectiveness  of  the  organization 
increases  as  the  amount  of  interdepartmental  coordination  for 
specific  activities  is  reduced. 

Question  #5.  A  proposed  solution  is  a  central 
organization  combining  the  functions  of  Computer  Services  and 
Information  Services,  headed  by  a  professional,  experienced 
Corporate  Information  Officer  reporting  directly  to  the 
Superintendent.  The  central  organization  responsibilities 
include  all  common  infrastructure  issues,  such  as  the  campus 
backbone,  network  connectivity,  campus-wide  e-mail,  life-cycle 
management,  software  licensing  and  configuration  management, 
data  standardization,  and  long-range  strategic  planning. 
Every  department/ code  provides  operation  and  maintenance  for 
their  specific  systems,  coordinated  through  the  central 
organization,  which  has  divisions  for  academic,  research, 
administrative,  library,  and  infrastructure  information 
systems . 

Question  #S.  The  functions  performed  by  the  Assistant  to 
the  Provost  duplicate  the  functions  performed  (or  assigned)  to 
numerous  other  organizational  codes  at  NPS.  The  Function  vs. 
Organizational  Unit  Matrix  (Tab  C  of  Appendix  D)  clearly  shows 
the  overlap  in  "Direct  Management  Responsibility"  between  the 
Provost's  Academic  Planning  Code  Oil  and  the  Dean  of  Faculty. 
The  Activity  Hierarchy  Diagram  Decomposition  (Tabs  M  and  N  of 
Appendix  D)  also  detail  this  functional  duplication.  The 
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budget  office  functions  duplicate  functions  assigned  to  and 
performed  by  the  Director  of  Resource  Management  and  his 
staff.  The  staff  administrative  office  functions  duplicate  or 
supplement  the  efforts  of  the  other  Deans'  staffs;  if  all  that 
is  required  is  additional  staff  for  surge  support,  a  rotating 
staff  pool  would  suffice.  The  functions  performed  by  the 
Office  of  Institutional  Research  directly  conflict  with  the 
responsibilities  of  the  Dean  of  Computer  and  Information 
Services  and  his  staff,  especially  the  position  of  Director  of 
Management  Information  Systems.  This  last  conflict  may  be 
unseen  due  to  the  prolonged  vacancy  in  the  MIS  Director 
position.  Restoration  of  all  these  functions  to  their 
assigned  codes  has  the  potential  to  significantly  reduce  the 
amount  of  duplicative  and  unproductive  effort;  key  to  this 
shift  of  responsibilities  is  the  improvement  of  management 
information  access  for  the  Provost /Academic  Dean. 

Question  #5.  Based  on  the  previous  answers,  the 
responsibilities  addressed  in  this  question  belong  to:  The 
Dean  of  Instruction  for  new  instructional  programs;  the  Dean 
of  research  for  new  research  centers;  the  Dean  of  Instruction 
for  new  instructional  laboratories;  the  Dean  of  Computer  and 
Information  Services  for  distance  learning  facilities;  the 
Director  of  Programs  for  international  programs. 
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D .  RESOURCE  CONSTRAINTS 

Although  a  discussion  of  resource  constraints  is  a  little 
out  of  place  in  this  chapter,  due  to  the  focus  on  the  NPS 
enterprise  information  architecture,  this  chapter  provides  the 
logical  venue  for  this  continuation  of  the  analysis  of  the  NPS 
enterprise.  The  resource  constraints  of  interest  consist  of 
financial  constraints  and  personnel  constraints,  as  discussed 
below. 

1.  Financial  Constraints 

Implementation  of  any  data  management  architecture 
requires  funding  for  many  items  related  to  the  underlying 
technical  infrastructure:  purchase  of  new  or  upgrade  to 
existing  hardware,  purchase  of  new  or  upgrade  to  existing 
software,  purchase  of  new  or  upgrade  of  existing  peripherals, 
hiring  new  IS  personnel,  training  new  and  existing  IS 
personnel,  training  new  and  existing  users,  conversion  of  data 
in  existing  databases,  and  so  on.  The  entire  NPS  enterprise 
bears  these  costs  for  an  enterprise-wide  architecture 
implementation,  not  just  a  single  department  or  organizational 
unit.  Therefore,  this  type  of  infrastructure  implementation 
impacts  all  sources  of  funding,  including  military 
appropriations  and  academic  department  reimbursable  funds. 

Determination  of  the  total  IS  budget  at  NPS  is  a 
difficult  task,  due  to  the  multiple  sources  of  funds, 
including  multiple  appropriations  (0&M,N  and  OPN)  and  multiple 
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funds  from  specific  reimbursable  research  activities. 
Additionally,  the  IS  budget  funds  many  categories  of  costs, 
including  hardware,  software,  peripherals,  maintenance 
contracts,  training,  and  personnel  wages  and  salaries.  An 
estimate  of  the  fiscal  year  1994  IS  budget  is  approximately 
$9M,  with  approximately  $5M  from  appropriated  funds  and  the 
remainder  from  reimbursable  funds. (FLDSUPPACT,  1994;  ASDP, 
1994) 

Review  of  the  individual  1994  Abbreviated  System 
Decision  Papers  (ASDPs)  submitted  by  the  academic  departments 
and  organizational  codes  in  lieu  of  an  IS/IT  budget  reveals 
this  total  amount  is  budgeted  to  support  the  initiatives, 
within  each  academic  department  and  organizational  code,  for 
the  development  of  new  or  upgraded  information  systems,  or  to 
provide  maintenance  for  existing  systems  in  addition  to  the 
new  systems.  (Chapter  VI  provides  additional  details  in  Table 
VI.  14.)  No  spare  funding  exists  for  the  implementation  of  an 
enterprise-wide  data  management  architecture  without  impacting 
all  organizational  units  and  their  individual  acquisition 
plans.  Implementation  delay  is  therefore  inevitable  due  to 
the  lack  of  immediately  available  funding  and  the  need  to  plan 
and  program  the  data  management  architecture  implementation 
into  the  budget  out-years. 
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2 .  Personnel  Constraints 

The  key  issue  with  respect  to  personnel  constraints  is 
the  availability  of  experienced  personnel  to  support  the 
transition  and  operation  of  a  new  data  management  architecture 
and  its  underlying  technical  infrastructure.  Either  existing 
personnel  have  the  requisite  training  and  experience,  and 
exist  in  sufficient  numbers  to  support  the  increased  data 
management  tasks,  or  NPS  must  hire  additional  personnel. 

Review  of  multiple  documents  provided  by  the  NPS  Code 
05  organization  outlining  the  NPS  mission  staff,  both  within 
the  Code  05  organization  and  throughout  the  entire  school 
provides  an  overview  of  the  information  system  support 
personnel  at  NPS.  A  memorandum  on  "Support  and  Research  Staff 
Levels"  (Lewis,  1994)  identifies  101  total  civilian  computer 
system  support  personnel  at  NPS,  distributed  throughout  21 
organizational  codes  or  academic  departments.  The  memorandum 
also  provides  a  partial  breakdown  of  personnel  skills  and 
experience  levels  in  the  three  largest  personnel  groups.  A 
listing  (HRO,  1994)  of  the  personnel  assigned  to  the  Computer 
and  Information  Services  Code  (Code  05)  reveals  numerous 
authorized  positions  are  vacant,  ranging  from  the  Dean  of 
Computer  and  Information  Services  (currently  filled  by  the 
Provost/Academic  Dean  as  the  Acting  Dean) ,  the  Director  of 
Academic  Computing  (also  filled  by  an  Acting  Director),  the 
Director  of  Management  Information  Services,  to  numerous  other 
supervisory  and  technical  positions.  As  of  the  05  May  1994 
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date  of  the  report,  a  total  of  15  positions  in  the  Code  05 
organizations  are  vacant.  Vacancies  also  exist  in  the  other 
academic  departments  and  organization  codes. 

The  high  number  of  vacant  key  personnel  positions,  and 
thus  a  corresponding  lack  of  technical  information  skills  and 
expertise  throughout  the  NPS  enterprise,  effectively  prevents 
implementation  of  any  new  data  management  architecture  at  NPS 
without  also  hiring  more  personnel.  Data  management  is  a 
problem  now;  the  data  management  requirements  for  any  other 
data  architecture  are  even  more  stringent  and  demanding.  NPS 
must  hire  and  train  sufficient  personnel  to  support  the 
increased  demands  of  a  new  data  architecture  and  its 
underlying  technical  infrastructure. 

E.  CHAPTER  SUMMARY 

This  chapter  provides  an  overview  top-level  analysis  of 
the  Naval  Postgraduate  School  and  its  information 
architecture.  The  analysis  develops  a  high-level  data  model, 
an  activity  or  function  model,  and  supporting  documentation. 
The  analysis  includes  a  discussion  of  several  questions  posed 
by  the  Provost /Academic  Dean  to  a  Committee  on  NPS  Mission 
Organization,  and  a  review  of  the  financial  and  personnel 
resource  constraints. 

The  following  chapter  provides  a  discussion  of  the 
alternative  data  management  architectures  and  technologies 
that  are  currently  available  for  implementation  at  NPS. 
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V.  DATA  MANAGEMENT  ARCHITECTURE  ALTERNATIVES 

This  chapter  provides  a  discussion  of  the  different  types 
of  data  management  architectures  analyzed  for  possible  use  by 
the  Naval  Postgraduate  School  enterprise,  and  addresses  the 
underlying  technical  infrastructure  architecture  issue. 

A.  DATA  MANAGEMENT  ARCHITECTURE  ALTERNATIVES 

The  design  of  any  data  management  architecture  is  highly 
dependent  on  the  underlying  technical  infrastructure,  which 
defines  the  type  of  processing  in  the  environment.  Therefore, 
any  discussion  of  data  management  architecture  alternatives 
first  requires  a  discussion  of  the  different  forms  of 
technical  infrastructure  architectures. 

1.  Technical  Infrastructure  Architectures 

The  structure  of  any  technical  architecture  generally 
involves  some  form  of  distributed  or  "cooperative"  processing, 
except  in  the  isolated  case  of  a  system  consisting  solely  of 
stand-alone  personal  computers  (PC) .  Distributed  processing 
consists  of  multiple  interconnected  processors  operating  at 
the  same  time.  Cooperative  processing  is  simply  a  subset  of 
distributed  processing;  whereas  the  goal  of  distributed 
processing  is  to  move  the  processing  as  close  to  the  user  as 
possible,  the  goal  of  cooperative  processing  is  to  move  the 
processing  to  whichever  component  is  best  suited  for  the  job 
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(Sprague  and  McNurlin,  1993,  p.  147) .  Another  name  for 
distributed  or  cooperative  processing  is  peer-to-peer 
processing,  based  on  the  roles  of  the  processors.  Peer-to- 
peer  processing  contrasts  with  the  concept  of  client/server 
processing.  Client/server  processing  is  simply  a  subset  of 
distributed  or  cooperative  processing,  wherein  one  processor 
generally  serves  as  a  "client",  making  requests  to  a  "server" 
processor.  Most  descriptions  of  client/server  processing 
categorize  five  specific  types,  varying  in  functionality  and 
complexity,  based  on  the  division  of  services  between  the  host 
(also  known  as  the  server)  and  the  desktop  computer  (also 
known  as  the  client) .  These  categories  apply  equally  to  the 
larger  superset  of  distributed  or  cooperative  processing 
systems  as  well.  Tony  Percy  (1994)  defines  these  five 
categories  as: 

1.  Distributed  Presentation 

2.  Remote  Presentation 

3.  Distributed  Function 

4 .  Remote  Data  Management 

5.  Distributed  Database 

Figure  V.l  provides  a  graphical  representation  of  the  service 
division  between  the  host  and  the  desktop  computers  for  each 
of  these  five  categories. 

In  distributed  presentation,  the  desktop  computer 
(client)  and  the  host  computer  (server)  share  the  presentation 
duties,  i.e.,  the  desktop  computer  typically  provides  a 
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Figure  V.l  Cooperative  Client/Server  Processing 
(Percy,  1994) 


graphical  user  interface  for  a  more  "user-friendly"  display 
and  interaction.  Another  name  for  the  new  user  interface  is 
"frontware";  the  interaction  is  also  called  "screen  scraping". 

In  remote  presentation,  the  desktop  computer  provides 
all  the  interface  functions  through  messages  to/from  an 
application  that  is  running  solely  on  the  host  computer.  This 
approach  allows  multiple  front-ends  access  to  the  same 
application.  (This  is  also  known  as  server-driven 
client/server  processing.) 

In  distributed  function,  the  desktop  computer  and  the 
host  computer  share  the  application  duties,  i.e.,  the 
application  running  on  the  desktop  submits  queries  in  the  form 
of  remote  procedure  calls  (RPC)  to  the  host  computer,  where 
standard  services  accomplish  the  request. 

In  remote  data  management,  the  desktop  computer 
contains  the  application  and  accesses  the  data  stored  on  the 
host  computer  when  required.  Typically  a  Data  Base  Management 
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System  (DBMS)  installed  on  the  host  provides  all  data 
management.  Any  preliminary  data  processing,  such  as  sorting, 
is  accomplished  on  the  host  computer  based  on  the  commands 
(usually  in  the  form  of  Structured  Query  Language  (SQL) 
statements)  sent  by  the  desktop  computer;  only  the  resultant 
data  is  returned  to  the  desktop  computer.  (This  is  also  known 
as  client-driven  client/server  processing.) 

In  distributed  database,  the  DBMS  controls  how  the 
desktop  computer  and  the  host  computer  share  the  data 
management  duties,  i.e.,  the  desktop  computer  may  download  a 
portion  of  the  host's  data  base  to  the  desktop,  and  locally 
perform  various  data  functions  such  as  sorting  and  report 
generation;  the  host  computer  may  perform  the  processor 
intensive  duties  such  as  the  initial  data  base  query  and 
preliminary  sorting. 

Many  different  forms  of  distributed  or  cooperative 
processing  systems  exist,  including; 

1.  A  system  consisting  of  a  mainframe  host  and  user 
terminals . 

2.  A  system  consisting  of  multiple  PCs  or  workstations 
connected  in  a  Local  Area  Network  (LAN) ,  with  or  without 
dedicated  servers. 

3.  A  system  consisting  of  a  mainframe  host  and  multiple  PCs 
or  workstations  connected  in  a  Local  Area  Network  (LAN) , 
with  or  without  other  dedicated  servers. 

4.  A  system  consisting  of  multiple  mainframe  hosts,  PCs, 
workstations,  and/or  LANs  connected  in  a  Metropolitan 
Area  Network  (MAN)  or  a  Wide  Area  Network  (WAN) . 
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The  evolution  of  distributed  processing  systems  follows  two 
converging  paths:  the  evolution  from  mainframe  hosts  and 
terminals  to  mainframe  hosts  and  workstations  (or  PCs)  and  the 
evolution  from  stand-alone  PCs  to  networked  PCs  (or 
workstations) .  Figure  V.2  graphically  portrays  this  evolution 
of  distributed  processing.  An  advanced  form  of  distributed 
processing  is  a  system  that  allows  multiple  different  machines 
using  different  operating  systems  on  different  types  of 
networks  to  cooperate  on  the  same  task. 

The  trend  in  information  system  technology  today  is 
toward  more  distributed  processing,  especially  in  the  area  of 
distributed  databases .  The  impetus  behind  this  trend  is 
twofold;  organizations  want  to  move  responsibility  for 
computing  resources  closer  to  the  actual  users,  and  they  want 
to  improve  the  use  of  computer  resources. 

Robert  Murray  (1991,  pp.  61-64)  defines  eight  phases 
in  the  migration  path  to  fully  distributed  processing  systems: 

1.  Host-based,  real-time  query  and  update. 

2.  Host-based,  real-time  query  and  update  with  additional 
query  through  file  transfers  to  PCs. 

3.  Host-based,  real-time  query  and  update  with  additional 
query  through  file  transfers  to  PCs  and  batch  updating 
permitted  from  PC  data. 

4.  Real-time  query  and  update  from  either  host  or  PC. 

5.  Homogeneous  cooperative  processing  without  two-phase 
commit,  where  like  databases  run  on  the  same  hardware  and 
system  software  platforms. 

6.  Heterogeneous  cooperative  processing  without  two-phase 
commit,  where  databases  run  on  a  mix  of  platforms. 
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Figure  V.2  Cooperative  Processing  Evolution 

(Sprague  and  McNurlin,  1993,  p.  146) 
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7.  Homogeneous  cooperative  processing  with  two-phase  commit. 

8 .  Heterogeneous  cooperative  computing  with  two-phase 
commit . 

Phase  one  is  the  traditional  on-line  information  system 
processing.  Phase  two  extends  the  traditional  host-based 
applications  to  allow  PCs  to  download  portions  of  a  database 
for  use  in  local  applications;  however,  no  capability  exists 
to  update  the  host  database.  Phase  three  adds  batch  update 
capability  from  a  PC.  Now  the  host  acts  as  a  "back-end" 
database  server  and  processor,  and  the  PC  acts  as  the  "front- 
end"  to  manipulate  and  update  the  local  data.  Phase  four 
simply  extends  the  capabilities  of  the  PC  to  allow  on-line 
vice  batch  updates  to  the  host  database.  Phase  five 
distributes  databases  across  similar  or  identical  platforms, 
but  without  a  two-phase  commit  capability Phase  six  simply 
extends  phase  five  to  multiple  types  of  platforms,  still 
without  two-phase  commit  capability.  Phase  seven  adds  the 
two-phase  commit  capability,  providing  a  true  distributed 
database.  Phase  eight  simply  extends  the  previous  phase  to 
heterogeneous  databases  on  mixed  hardware  platforms.  (Sprague 
and  McNurlin,  1993,  pp.  166-167) 


Two-phase  commit  is  a  method  to  ensure  data  integrity; 
the  method  uses  a  two-step  process  to  lock  and  update  all 
duplicate  copies  of  data  before  any  of  the  affected  databases 
are  committed  to  the  update.  If  any  of  the  updates  fail,  the 
transaction  is  not  completed,  i.e.,  backed  out.  (Sprague  and 
McNurlin,  1993,  p.  167) 
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2.  Data  Management  Architectures 

The  system’s  data  storage  design  typically  drives  the 
structure  of  the  system's  data  management  architecture. 
Sprague  and  McNurlin  (1993,  p.  213-219)  identify  several 
different  types  of  data  storage  approaches: 

1.  Downloaded  Data  Files 

2.  Multiple  Stored  Copies  of  Data 

3.  Unsynchronized  Distributed  Databases 

4.  "True"  Distributed  Databases 

5.  Client/server  Databases 

6.  Federated  Databases 

Discussions  of  each  of  these  approaches  is  provided  in  the 
following  sections. 

a.  Downloaded  Data  Files 

Downloading  data  from  a  mainframe  (or  minicomputer 
or  server)  is  one  of  the  most  common  data  distribution  methods 
in  use  today.  This  resource-sharing  approach  covers  a  wide 
range  of  options,  including:  distribution  of  reports,  download 
of  selected  data  files,  and  even  (rarely)  updates  of  data 
files  to  the  host.  The  most  prevalent  uses  for  this  type  of 
architecture  are  query  and  reporting  from  downloaded  data. 
Figures, V.  3  and  V.4  provide  a  graphical  depiction  of  this  data 
management  architecture. 

Four  potential  problems  with  downloading  data  are 
coordination,  consistency,  access  control,  and  computer  crime. 
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Figure  V.3  Resource  Sharing  of  Downloaded 
(Mainframe  as  server) 

(Kroenke,  1992,  p.  524) 
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Figure  V 


4  Resource  Sharing  of  Downloaded  Data 
(gateway  microcomputer  as  server) 
(Kroenke,  1992,  p'.  525) 
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Coordination  refers  to  coordination  of  database  management 
actions  between  the  client  computer  and  the  server  computer. 
Consistency  refers  to  control  over  local  updates  to  downloaded 
data.  Access  control  refers  to  protecting  against 
inappropriate  but  legal  behavior;  computer  crime  refers  to 
illegal  behavior,  such  as  data  theft.  (Kroenke,  1992,  p. 
528) 

Sometimes  the  data  distribution  is  indirect, 
through  the  use  of  an  "extract"  file  or  other  information 
database;  the  data  is  then  downloaded  from  the  intermediate 
database  by  the  users.  Data  warehouses  are  a  special  purpose 
form  of  an  information  database,  and  their  conceptual  use  is 
sufficiently  important  to  warrant  separate  discussion  in  a 
later  section  of  this  chapter. 

Jb.  Multiple  Stored  Copies  of  Data 

Multiple  specified  locations  (servers)  store 
duplicate  copies  of  the  databases  (through  a  process  known  as 
"replication"),  and  make  them  accessible  to  the  users  for 
processing  queries  and  updates.  Infrequent  but  periodic 
updates  occur  to  the  centrally  maintained  databases,  usually 
through  a  formally  controlled  batch  process  after  working 
hours;  after  updating,  the  central  databases  download  the 
updates  to  all  the  remote  locations.  Lack  of  data  integrity 
at  the  remote  locations  between  updates  is  an  obvious 
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shortcoming  of  this  approach,  but  it  is  generally  not  a 
critical  issue  for  those  organizations  which  choose  to 
implement  this  method. 

c.  Unsynchronized  Distributed  Databases 

The  use  of  unsynchronized  distributed  databases  is 
similar  to  the  use  of  multiple  stored  copies  of  data,  since  in 
both  cases  the  databases  update  relatively  infrequently  but  at 
periodic  intervals.  The  difference  lies  in  the  timing  of  the 
updates;  in  unsynchronized  distributed  databases  the  secondary 
copy  of  the  distributed  database  typically  updates  itself  more 
frequently,  at  regular  periodic  intervals  or  triggered  by  some 
event,  as  opposed  to  once  in  any  given  day.  This  approach 
provides  a  mechanism  for  improved  data  access  performance  when 
data  integrity  is  not  a  critical  issue,  and  the  error  can  be 
caught  quickly  and  fixed  easily. 

Several  large  database  vendors  have  commercial 
implementations  of  this  type  of  data  management  architecture, 
using  different  types  of  database  replication.  Some 
replication  engines  allow  data  to  be  updated  at  regular  timed 
intervals;  others  provide  replication  based  on  trigger  events, 
such  as  an  update.  Still  others  operate  continuously,  using 
a  store-and- forward  mechanism  to  update  secondary  databases 
with  primary  data  whenever  updates  occur.  Store-and- forward 
replication  also  provides  a  mechanism  to  rapidly  recover  from 


125 


a  secondary  site  failure.  Figure  V.5  provides  a  graphical 
depiction  of  some  of  the  replication  mechanisms. 

Generally,  all  replication  mechanisms  use  two- 
phase  commit  methods  to  ensure  data  integrity;  but  the 
implementations  vary  between  vendors.  Some  vendors  use  two- 
phase  commit  for  each  and  every  replication,  thereby  ensuring 
that  all  copies  of  the  data  are  100  per  cent  consistent  at  all 
times.  Other  vendors  define  a  primary  copy  for  every  piece  of 
data,  which  gets  updated  first  using  two-phase  commit 
procedures,  and  then  replicates  the  data  to  all  the  secondary 
sites  asynchronously  and  independently;  although  this  may 
result  in  a  data  integrity  issue  between  copies,  in  most  cases 
the  total  replica  distribution  occurs  in  seconds.  (Baum, 
1994a;  Skrinde,  1994) 

d.  "True"  Distributed  Databases 

Two  definitions  exist  for  true  distributed 
databases;  the  first  definition  consists  of  a  distributed, 
non-duplicated  database  and  the  second  consists  of  distributed 
duplicate  copies  of  the  database.  Figure  V.6  provides 
examples  of  these  and  other  types  of  distributed  databases. 
In  a  database  that  has  been  partitioned  and  distributed 
throughout  a  system  without  duplication,  any  portion  of  the 
database  is  accessible  from  any  processing  node  (subject  to 
access  control)  .  Applications  (and  users)  need  not  know  where 
a  particular  portion  of  data  resides  --  the  system  keeps  track 
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Figure  V.5  Distributed  Database  Replication  Modes 
(Skrinde,  1994) 
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Figure  V.6  Types  of  Distribute 
(Kroenke,  1993,  p. 


of  that  transparently.  In  a  database  that  has  been  duplicated 
(replicated)  and  distributed  throughout  a  system,  the  same 
data  resides  at  each  location.  Again,  applications  (and 
users)  need  not  know  where  a  particular  portion  of  data 
resides,  since  they  have  access  to  all  the  data  at  any 
location.  However,  data  synchronization  to  maintain  data 
integrity  is  a  significant  problem  in  this  approach. 

The  definitive  operating  principles  for  the 
distributed  database  field  are  the  definitions  contained  in 
Chris  Date's  (1987)  twelve  rules  for  a  distributed  database 
and  Michael  Stonebraker ' s  (1986)  seven  kinds  of  transparency. 
The  twelve  rules  are  listed  in  Figure  V.7  and  the  seven  types 
of  transparency  are  listed  in  Figure  V.8.  Implicit  in  these 
distributed  database  operating  principles  is  the  requirement 
that  the  underlying  databases  be  relational  databases. 

Sprague  and  McNurlin  (1993,  p.  216)  declare  that 
the  three  biggest  challenges  facing  the  designers  of  true 
distributed  systems  are:  choosing  a  standard  data  access 
language,  synchronizing  distributed  databases,  and  optimizing 
queries.  The  current  standard  data  access  language  is  SQL. 
(SQL  is  discussed  in  greater  detail  in  Appendix  E, 
Middleware.)  Synchronizing  distributed  databases  requires 
implementation  of  the  two-phase  commit  (or  similar) 
methodology,  preferably  at  the  databases  and  not  in  the 
applications.  Optimizing  queries  requires  an  intelligent 
query  optimizer  that  can  rapidly  analyze  changing  system 
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1.  Local  autonomy.  Local  data  is  owned  and  managed  locally,  with  local 
accountability  and  security.  No  site  depends  on  another  for  successful 
functioning. 

site.  All  sites  are  equal,  and  none  relies  on  a  master 
site  for  processing  or  communications. 

3.  Continuous  operation.  Installations  at  one  site  do  not  affect  operations  at 
another.  There  should  never  be  a  need  for  a  planned  shutdown.  Adding  or 
dGlehTig  installations  should  notaffect  existing  programs  or  activities.  Likewise, 

able  to  be  created  and  destroyed  without 

stopping  any  component. 

4.  Location  ^dependence  (transparency).  Users  do  not  have  to  know  where  data 
is  physically  stored.  They  act  as  if  all  data  is  stored  locally. 

5.  Fra^entation  independence  (transparency).  Relations  between  data  elements 
can  be  fragmented  for  physical  storage,  but  users  are  able  to  act  as  if  the  data 
was  not  fragmented, 

6.  Replicafion  mdependence.  Relations  and  fragments  can  be  represented  at  the 
physical  level  by  multiple,  distinct,  stored  copies  or  replicas  at  distinct  sites, 
transparent  to  the  user. 

7.  Distributed  query  processing.  Local  computer  and  input/output  activity  occurs 
at  multiple  ^es,  with  data  communications  between  the  sites.  Both  local  and 
global  optimization  of  query  processing  are  supported.  That  is,  the  system  finds 
the  cheapest  way  to  answer  a  query  that  involves  accessing  several  databases. 

8.  Distributed  transaction  management  Single  transactions  are  able  to  execute 
code  at  multiple  sites,  causing  updates  at  multiple  sites. 

9.  Hardware  mdependence.  Distributed  database  systems  are  able  to  run  on 
different  kinds  of  hardware  with  all  machines  participating  as  equal  partners 
where  appropriate. 

10.  Opeiatnig  system  independence.  Distributed  database  systems  are  able  to  run 
under  different  operating  systems. 

1 1 .  Network  independence.  Distributed  database  systems  are  able  to  work  with 
different  communications  networks. 

12.  Database  mdependence.  Distributed  database  systems  are  able  to  be  built  of 
different  kinds  of  databases,  provided  they  have  the  same  interfaces. 


Figure  V.7  Twelve  Rules  for  Distributed  Databases 
(Sprague  and  McNurlin,  1993,  p.  214) 
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conditions  to  determine  the  fastest  and  most  efficient  steps 
to  handle  the  query. 


1 .  Location  transparency.  A  user  can  submit  a  query  that  accesses  distnbuted 
objects  without  having  to  know  where  the  objects  are. 

2.  Performance  transparency.  A  distributed  query  optimizer  finds  the  best  plan  for 
executing  a  distributed  command,  which  means  that  a  query  can  be  submitted 
from  any  node  in  a  distributed  database  and  it  will  run  with  comparable 
performance. 

3.  Copy  transparency.  The  system  supports  the  optional  existence  of  multiple 
copies  of  database  objects. 

4.  Transaction  transparency.  A  user  can  run  a  transaction  that  updates  data  at  a 
number  of  sites.  It  behaves  exactly  tike  a  local  one,  with  the  ultimate  effect 
being  that  it  either  commits  or  aborts;  no  intermediate  states  are  possible. 

5.  Fragment  transparency.  The  distributed  DBMS  allows  a  user  to  cut  up  a 
relation  into  multiple  pieces  and  place  them  at  multiple  sites  according  to  cert^n 
distribution  criteria. 

6.  Schema  change  transparency.  Users  who  add  or  delete  a  database  object  from 
a  distributed  database  only  need  make  the  change  once  to  the  distributed 
dictionary.  They  do  not  need  to  change  the  catalogs  at  all  sites  that  participate 
in  the  distributed  database. 

7.  Local  DBMS  transparency.  The  distributed  database  system  is  able  to  provide 
its  services  without  regard  for  the  local  DBMSs  that  are  actually  managing  local 


FigurG  V.8  Seven  Types  of  Transparency 

(Sprague  and  McNurlin,  1993,  p.  215) 

e.  Client/ Server  Databases 

Client/server  databases  are  very  similar  to  true 
distributed  databases,  with  one  significant  exception.  The 
difference  involves  the  concept  of  location  independence  or 
transparency;  client/server  databases  do  not  support  the 
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concept  of  location  transparency.  In  a  client/server 
environment,  the  DBMS  only  runs  at  selected  locations; 
therefore  the  applications  (users)  must  know  where  the  DBMS  is 
located  to  be  able  to  access  the  data.  Niimerous  client/server 
databases  operate  in  organizations  throughout  the  world  today. 

The  different  forms  of  client/server  processing 
are  the  five  types  illustrated  in  Figure  V.l,  and  need  not  be 
repeated  here.  The  resources  immediately  at  hand  typically 
drive  the  decisions  on  how  to  distribute  processing  among 
clients  and  servers.  For  many  organizations,  the  historical 
"legacy"  data  is  stored  on  a  mainframe  computer.  No  strategy 
for  migration  to  a  client/server  technology  can  ignore  this 
data,  and  its  accessibility.  One  way  for  an  organization  to 
make  their  legacy  data  available,  and  also  preserve  a  large 
hardware/software  investment,  is  to  make  the  organizational 
mainframe  computer  a  server. 

(1)  Mainframe  as  Server.  With  the  advances  in 
computer  technology,  and  the  increases  in  processing  power 
available  in  smaller  units,  mainframes  are  no  longer  accessed 
primarily  for  their  processing  power,  but  for  the  information 
that  resides  there.  Therefore,  the  mainframe  can  act  as  a 
master  server  in  an  enterprise  network,  aided  by  other 
intelligent  servers  acting  as  clients  to  the  mainframe  server. 
Unfortunately,  due  to  the  incompatibilities  of  hardware. 
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system  software,  database  structures,  and  application 
programs,  a  mainframe  has  limits  on  the  role  as  a  server. 

Several  approaches  exist  for  a  mainframe  in 
the  server  role:  a  LAN  file  or  printer  server,  a  database 
query  server,  and  an  application  server.  Mainframes  have 
tremendous  disk  storage  capacities  and  fast  laser  printers  for 
bulk  printing  jobs.  IBM  and  other  mainframe  vendors  provide 
numerous  products  to  support  the  mainframe's  use  as  servers. 
A  sampling  from  IBM's  list  includes:  LAN  Resource  Extension 
and  Services,  which  provide  disk  serving,  data  distribution, 
LAN  to  host  printing,  host  to  LAN  printing,  and  LAN 
administration;  Workstation  LAN  File  Services,  which  provides 
a  fast,  large-scale  file  server;  the  Data  Facility  Distributed 
Storage  Manager,  which  supports  multiple  vendor  hardware 
client  platforms;  and  support  for  a  wide  range  of  network 
connectivity  options.  Client/server  file  sharing  using  a 
mainframe  generally  requires  the  mainframe  to  emulate  every 
database  action,  which  is  woefully  inefficient.  However,  use 
of  a  mainframe  as  a  SQL-based  query  server  provides 
significant  processing  power  when  required  for  querying  large 
databases.  Justifying  the  use  of  a  mainframe  as  an 
application  server  requires  either  a  pre-existing  mainframe 
database  or  a  large  user  population  uniquely  supported  by  the 
mainframe.  Two  example  areas  where  mainframes  generally 
fulfill  these  criteria  is  in  office-system  support  and  imaging 
systems . 
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A  mainframe  requires  several  architectural 
changes  to  improve  its  role  as  a  server.  These  changes 
include:  greater  on-line  disk  capacity,  and  improved  seek 

performance  in  disk  systems.  The  improved  seek  performance 
results  from  drive  enhancements,  disk  drive  head  queuing,  use 
of  Redundant  Arrays  of  Independent  Disks  (RAID)  in  a  "disk 
striping"  mode,  and  caching.  Other  improvements  include 
mechanisms  to  improve  interconnectivity,  such  as 
communications  gateways  and  other  LAN  connections.  Finally, 
the  mainframe  requires  improved  vendor  support  for  several 
systems  management  issues,  including  software  distribution, 
database  reconciliation,  and  remote  operation  and 

administration.  (Nolle,  1994;  Salemi,  1993) 
f.  Federated  Databases 

The  author  defines  a  federated  database  system  as 
a  system  that  uses  autonomous  heterogeneous  databases. 
Frequently  (but  not  always)  the  databases  store  incompatible 
data  types,  such  as  text,  audio,  video,  images;  use  of  a 
federated  database  system  avoids  the  problems  associated  with 
storing  all  the  different  data  types  in  one  single  database. 
The  application  consolidates  the  data  from  each  separate  type 
of  database  and  displays  it  in  whatever  format  is  required. 
Federated  database  systems  require  data  access  tools 
(middleware)  to  retrieve  the  mixed  format  data  from 
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heterogeneous  databases  on  mixed  platforms.  Appendix  E 
discusses  data  access  methods  and  middleware. 

3.  Data  Warehouses 

As  previously  mentioned,  data  warehouses  are  a  form  of 
information  database.  Although  industry  uses  the  term  data 
warehouse  for  nxamerous  concepts,  the  three  most  prevalent  are: 
an  aggregated  information  database  based  on  extracted 
operational  data  structured  to  support  Decision  Support 
Systems  (DSS)  and  Executive  Information  Systems  (EIS) ,  an 
enterprise  data  bus,  and  an  all-source  information  database, 
containing  operational,  external,  and  other  internal  data. 

The  primary  data  warehouse  concept  arises  from  a  need 
for  a  better  method  of  gathering  and  maintaining  decision 
support  data,  or  the  desire  to  gain  informational  access  as 
opposed  to  operational  access  to  corporate  data.  Operational 
access  is  access  to  the  current  state  of  specific  data 
instances;  informational  access  applies  to  large  voliames  of 
corporate  data  for  higher  level  assessment,  planning,  and 
strategic  decision-support  activities.  Two  environmental 
conditions  drive  this  need.  First,  the  operational 
transaction  processing  environment  provides  no  historical 
perspective  for  use  in  decision-making.  Second,  operational 
data  is  not  easily  accessible  to  decision  makers  —  someone 
must  first  locate  and  extract  the  appropriate  data,  verify  it, 
summarize  it,  integrate  it  with  data  from  other  sources. 
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organize  it  for  a  specific  purpose,  and  then  move  it  into  a 
database  where  it  can  be  easily  and  uniformly  accessed  by  the 
managers  who  need  it.  A  requirement  to  repeat  the  entire 
process  every  time  an  analysis  is  performed  proves  this 
approach  is  inefficient  and  expensive.  Industry's  proposed 
evolutionary  solution  is  the  data  warehouse: 

The  data  warehouse  provides  the  architecture  to  model, 
map,  filter,  integrate,  condense,  and  transform  data  into 
meaningful  information  that  can  be  accessed,  analyzed,  and 
acted  upon.  It  keeps  track  of  the  data's  source  and  its 
target  table  within  the  database,  with  a  time  stamp  to 
ensure  that  users  compare  apples  to  apples.  (Ashbrook, 
1993)  ' 

Operational  data  is  filtered  based  on  predetermined  user 

selection  criteria,  summarized  over  a  time  horizon,  and 

further  focused  and  integrated  with  other  data  as  it  moves 

into  the  data  warehouse.  Figure  V.9  provides  a  graphical  view 

of  a  data  warehouse  architecture.  (Ashbrook,  1993;  Inmon, 

1994;  Red  Brick,  1993;  Ferrara  and  Naecker,  1993) 

An  organization's  evolution  to  data  warehousing  has 

three  basic  stages:  application  access,  the  information 

center,  and  the  data  warehouse.  Application  access  implies 

that  informational  access  is  obtained  by  users  through  a 

request  to  the  IS  department  for  another  report  against  an 

operational  production  database.  This  stage  further  evolves 

as  end-user  data  access  tools  proliferate,  and  the  IS 

department  is  removed  as  a  bottleneck.  The  second  stage, 

information  center,  is  really  a  small-scale  (i.e., 

departmental)  data  warehouse,  where  data  from  one  or  more 
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operational  systems  is  extracted  into  an  information  database. 
Because  the  information  center  database  is  separate  from  the 
operational  data,  database  structure  and  data  element 
definition  standardization  can  take  place,  simplifying  end- 
user  access.  Some  industry  analysts  champion  the  information 
center  "datamart"  idea  as  a  more  useful  and  affordable 
resource  than  a  data  warehouse,  based  on  an  assumption  that 
only  a  subset  of  the  corporate  data  is  relevant  to  a 
particular  group  of  users  (Wallace,  1994) .  This  stage  evolves 
to  a  condition  where  multiple  information  centers  exist,  each 
addressing  a  different  type  of  need.  The  next  stage  is  the 
data  warehouse.  The  key  difference  between  the  data  warehouse 
and  the  information  center  is  scope.  A  data  warehouse  is  a 
fully  architected,  enterprise-wide  informational  access 
environment.  (Ferrara  and  Naecker,  1993) 

Another  perspective  on  the  evolution  of  the  data 
warehouse  is  provided  by  Colin  White  (1993) .  White  defines 
four  approaches  along  the  evolutionary  path  leading  to  data 
warehousing.  In  the  first  approach  business  users  apply  host- 
based  decision  support  tools  against  a  centralized  operational 
database.  This  is  a  traditional  approach  for  providing  end 
users  with  access  to  corporate  data.  A  significant  amount  of 
this  type  of  processing  uses  batch-oriented  report  and  data- 
analysis  programs  that  access  and  process  file  and  non¬ 
relational  database  data  (legacy  data) ,  although  newer  tools 
also  access  relational  databases.  The  second  approach 
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provides  business  users  with  workstation-based  decision 
support  tools  that  access  centralized  enterprise-level  and. or 
decentralized  departmental  operational  databases.  This 
approach  is  typical  of  many  client/server  applications  today, 
which  allow  business  users  to  access  operational  databases 
through  database  gateway  middleware.  The  third  approach 
involves  creation  of  an  informational  database  by  copying  data 
from  the  operational  databases,  and  then  providing  the  end 
user  with  appropriate  decision  support  (query  and  report) 
tools  to  access  the  data  in  the  information  database,  again 
through  database  middleware.  This  approach  reduces  the 
performance  impact  of  end-user  decision  support  processing 
against  the  operational  databases.  The  final  approach  is 
similar  to  the  third,  except  that  now  the  information  database 
is  formally  structured,  and  the  data  is  transformed  to  enhance 
its  functionality.  This  approach,  the  enhanced  informational 
database,  is  the  data  warehouse  concept. 

Four  attributes  distinguish  the  data  in  a  data 
warehouse:  subject-oriented,  integrated,  time-variant,  and 
nonvolatile.  The  data  is  organized  around  major  subjects,  not 
processes.  The  data  has  consistent  data  element  definitions 
and  consistent  data  structures  in  order  to  integrate  the 
multiple  sources  and  types  of  operational  source  data.  The 
data  provides  a  historical  perspective,  because  it  is  accurate 
as  of  specific  moments  in  time;  in  effect,  the  data  provides 
a  series  of  "snapshots"  taken  over  a  long  time  horizon. 
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Finally,  the  data  does  not  change  over  time;  data  is  added  to 
the  warehouse,  but  the  data  in  the  warehouse  is  never  changed 
(unless  to  correct  an  input  error) .  (Inmon,  1994;  Ashbrook, 
1993;  Wallace,  1993) 

W.H.  Inmon,  author  of  the  landmark  work  on  data 
warehousing.  Building  the  Data  Warehouse  (QEI  Press, 
Wellesley,  Massachusetts),  lists  the  following  structural 
components  of  a  data  warehouse:  meta  data,  current  detail 
data,  older  detail  data,  lightly  summarized  data,  and  highly 
summarized  data.  Figure  V.IO  graphically  depicts  this 
structure.  The  primary  component  is  the  current  detail  data, 
which  is  the  most  recent  data,  stored  at  the  lowest  level  of 
granularity.  Older  detail  data  is  infrequently  accessed,  so 
it  is  usually  stored  on  some  form  of  mass  storage  that  does 
not  provide  instant  access  to  the  data.  The  lightly 
summarized  and  highly  summarized  data  provide  multiple  levels 
of  aggregation,  resulting  in  compact  and  easily  accessible 
data.  Meta  data  provides  the  directory  to  help  an  analyst 
locate  specific  contents  in  the  data  warehouse;  guides  the 
mapping  of  operational  data  through  its  transformation  to  the 
data  warehouse  data  structure;  and  defines  the  algorithms  used 
for  the  summarization  and  aggregation.  Figure  V.ll  provides 
an  example  of  the  different  levels  of  data  aggregation. 
Figure  V.12  provides  an  example  of  the  internal  structure  of 


140 


the  current  detail  data  component  of  a  data  warehouse 
structured  for  a  manufacturing  environment.  (Inmon,  1994,  p. 
1-15) 

Other  data  is  frequently  stored  within  the  data 
warehouse  even  though  it  is  not  derived  from  operational  data. 
Data  obtained  from  external  sources,  such  as  commercially 
available  demographic  data  and  market  analysis  data,  is  a 
frequent  addition  to  the  types  of  data  stored.  Another  type 
of  data  stored  is  data  required  to  be  permanently  maintained 
at  a  specified  level  of  detail  for  ethical  or  legal  reasons, 
such  as  occupational  health  and  safety  records.  Finally, 
public  summary  data  is  internal  data  that  is  calculated 
outside  the  boundaries  of  the  data  warehouse,  but  used 
throughout  the  organization.  An  example  of  public  summary 
data  is  the  quarterly  reports  prepared  by  public  corporations 
for  the  Securities  and  Exchange  Commission  (SEC) .  (Inmon, 
1994,  p.  15;  Ferrara  and  Naecker,  1993) 

Data  warehouse  management  software  consists  of  four 
tools:  the  data  warehousing  software,  which  provides  the 
user-specified  transformations  of  the  operational  data;  the 
data  warehouse  DBMS,  which  is  usually  any  relational  DBMS, 
(although  specialized  RDBMSs  also  exist) ;  data  access  and 
reporting  tools,  which  provide  the  end-users  the  means  to 
obtain  and  manipulate  the  data;  and  the  database  connectivity 
software,  or  middleware,  which  allows  the  end-user  front  end 
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Figure  V.IO  The  structure  of  data  inside  a  data  warehouse 
(Inmon,  1994,  p.  7) 
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Figure  V.ll  Data  warehouse  data  aggregation  example 
(Inmon,  1994,  p.  9) 
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Figure  V.12  Current  detailed  data  internal  structure 
(Inmon,  1994,  p.  14) 
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applications  to  communicate  with  the  databases.  Numerous 
vendors  provide  products  for  each  of  these  types  of  tools. 

B.  CHAPTER  SUMMARY 

This  chapter  provides  a  technical  overview  of  the  many 
different  types  of  data  management  approaches  available  to 
support  development  of  systems  to  implement  an  information 
architecture.  One  or  more  of  these  technologies  apply  to  any 
attempt  to  define  the  Naval  Postgraduate  School's  information 
architecture  implementation.  The  next  chapter  discusses  the 
steps  involved  in  an  analysis  of  the  NPS  requirements  and 
these  different  alternatives. 
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VI .  NPS  REQUIREMENTS  AND  DATA  MANAGEMENT  ALTERNATIVES 

Systems  Analysis  and  Design  literature  contains  numerous 
discussions  of  the  different  methods  for  conducting 
requirements  analysis;  most  of  these  methods  generally  have 
several  points  in  common.  Federal  and  DoD  acquisition 
regulations  also  address  requirements  analysis,  and  provide 
specific  guidance  on  minimum  requirements.  This  thesis 
research  uses  the  information  system  (IS)  requirements  and 
alternatives  analyses  guidelines  found  in  the  Federal 
Information  Resources  Management  Regulations  (FIRMR) (41  CFR 
201),  supported  by  the  discussions  in  a  supplemental  guide 
published  by  the  General  Services  Administration  (GSA)  ,  A 
Guide  for  Requirements  Analysis  and  Analysis  of  Alternatives 
(GSA-IRMS,  1990) .  The  FIRMR  identifies  numerous  factors  to  be 
considered  during  any  IS  requirements  analysis;  these  are 
briefly  outlined  in  the  first  section  of  Appendix  F. 
Similarly,  the  FIRMR  includes  several  procedures  for  the 
conduct  of  the  analysis  of  alternatives;  these  are  briefly 
described  in  the  second  section  of  Appendix  F. 

The  first  section  of  this  chapter  contains  the  NPS 
information  architecture  requirements  analysis  conducted  for 
this  thesis,  and  the  second  section  contains  the  data 
management  architecture  alternatives  analysis. 
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A.  ANALYSIS  OF  NFS  INFORMATION  ARCHITECTURE  REQUIREMENTS 

This  analysis®  of  NFS  information  architecture 
requirements  does  not  strictly  conform  to  the  guidance  in  the 
FIRMR  and  the  GSA  supplemental  guide.  An  information 
architecture  is  not  a  system;  therefore,  requirements  analysis 
procedures  designed  for  systems  are  not  entirely  suitable  for 
use  in  this  case.  However,  the  analysis  of  the  requirements 
for  the  NFS  information  architecture  attempts  to  incorporate 
as  many  points  from  the  FIRMR  and  GSA  guide  as  possible. 

The  requirements  analysis  process  includes  gathering 
information  on  the  following:  the  NFS  mission,  NFS  functional 
areas,  and  NFS  organizational  information  needs;  the  current 
NFS  information  architecture  and  its  component  parts;  and  a 
projection  of  future  NFS  needs,  drawing  upon  NFS  Component 
Information  Management  Flans  (CIMF)  and  the  draft  NFS 
Information  Systems  Vision  proposed  by  the  Computer  Advisory 
Board  (CAB) . 

The  information  collected  consists  of  overall  and  top- 
level  overview  data,  as  described  and  analyzed  in  Chapter  IV. 
This  requirements  analysis  only  covers  the  area  of  the 
information  architecture,  and  no  other  related  issues  —  such 
as  supporting  system  technology  and  network  infrastructure 
requirements.  Due  to  the  top-level  overview  nature  of  this 


®The  FIRMR  policy  regarding  requirements  analysis  states 
that  the  scope  of  the  analysis  should  be  "commensurate  with 
the  size  and  complexity  of  the  needs"  (41  CFR  201-20.102). 
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approach,  this  requirements  analysis  is  also  only  a  broad 
overview  of  a  future  NPS  information  architecture's 
requirements,  and  [regrettably]  not  a  very  detailed  or  in 
depth  analysis,  A  full  requirements  analysis  requires  a 
significantly  more  in— depth  analysis  of  not  only  the  current 
information  architecture  but  also  all  the  supporting 
infrastructure  and  technology  issues  to  refine  the  needs. 

1 .  Information  Needs  or  Requirements 

The  factors  that  determine  and  define  NFS's 
information  needs  with  respect  to  an  information  system  (or 
architecture)  are  many  and  varied.  The  following  listing  only 
provides  a  broad  overview  of  each  factor,  not  the  detailed  and 
comprehensive  analysis  that  would  be  required  to  fully 
determine  the  detailed  requirements.  The  factors  include: 
a.  Information  Sourcss 

Information  sources  identify  the  information 
currently  being  received  in  the  organization,  from  internal 
and  external  sources,  and  address  the  issue  of  missing 
information. 

(1)  Internal  Information  Sources.  Internal 
information  sources  are  the  sources  within  the  NPS 
organization  that  generate  information  used  in  information 
systems  throughout  the  enterprise.  These  sources  directly 
correlate  to  the  organizational  units  responsible  for  the 
creation  of  data  entities  (instances  of  a  data  entity  type) 
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identified  in  the  Chapter  IV  analysis;  therefore  only  a 
partial  listing  is  included  here  in  Table  VI. 1  as  an  example. 


Table  VI. 1  INTERNAL  INFORMATION  SOURCES 


information  Source 

Data  Entity  (infonnation) 

Academic  Chairs,  Dean  of  Instruction 

Academic  Course  Instruction 

Provost/Academic  Dean 

Academic  Dept  or  Group 

Academic  Associates,  Academic  Chairs 

Academic  Plan 

Academic  Associates,  Academic  Chairs 

Academic  Program 

Curricular  Officers,  Director  of  Programs 

Curricular  Plan 

Curricular  Officers,  Director  of  Programs 

Curricular  Program 

Superintendent 

Agreement 

Director  of  Resource  Management,  Comptroller 

Appropriated  Fund 

Director  of  Admissions,  Dean  of  Students 

NPS  Student 

(2)  External  Information  Sources.  External 
information  sources  are  the  sources  outside  the  NFS 
organization  that  provide  information  used  in  information 
systems  throughout  the  enterprise.  Table  VI.  2  provides 
examples  of  external  sources. 

Table  VI. 2  EXTERNAL  INFORMATION  SOURCES 


Infonnation  Source 

Data  Entity  (Infonnation) 

Major  Claimant,  Resource  Sponsor 

NPS  Budget 

Office  of  Personnel  Management,  SECNAV 

Civilian  NPS  Faculty.  Civilian  NPS  Staff 

Curriculum  Sponsor 

Curricular  Program,  Curricular  Plan 

Chief  of  Naval  Personnel  (SUPERS) 

Military  NPS  Student.  Military  NPS  Staff 
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(3)  Missing  Information.  Missing  information  is 
the  internal  or  external  information  that  is  needed  by  a  user 
but  is  not  currently  being  determined  or  received.  Every 
organizational  unit,  from  the  highest  level  to  the  lowest 
level  in  the  organization,  has  missing  information.  Table 
VI. 3  provides  examples  of  missing  information. 

Table  VI. 3  MISSING  INFORMATION 


Organizational  Unit 

Missing  Infonnation 

Provost 

NPS  output  measurements 

Provost,  Dean  of  Faculty 

Faculty  background  data 

Comptroller 

Dynamic  budget  data  updates 

Academic  Associates 

Student  data 

b .  Informa,  txon  Ou tpu ts 

Information  not  only  flows  into  the  organization, 
but  also  flows  outward,  in  the  form  of  information  outputs. 

(1)  Information  Outputs  to  Agencies.  NFS 
organizational  units  provide  information  to  many  external 
agencies.  Table  VI. 4  provides  examples  of  information  outputs 
to  other  agencies. 

Table  VI. 4  INFORMATION  OUTPUTS  TO  AGENCIES 


Infonnation  Output 

Agency 

Curricular  Programs 

Curricular  Sponsors 

POM  Budget  Submission 

Comptroller  of  the  Navy 

Accounting  Data 

Navy  Regional  Finance  Center 

Financial  Audits 

Navy  Audit  Service 
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{2)  Information  Outputs  to  the  Public.  NPS  also 
provides  information  directly  to  the  public,  as  opposed  to 
agencies.  Table  VI. 5  provides  examples  of  these  types  of 
information  outputs . 

Table  VI. 5  INFORMATION  OUTPUTS  TO  PUBLIC 


Information  Output 

Public  Organization 

Press  Interviews 

Local  area  media  representatives 

News  Releases 

Local  area  media  representatives,  general  public 

Command  Newspaper 

General  public 

Query  Responses 

Local  area  media  representatives,  general  public 

c.  Information  Relationships 

Information  relationships,  or  data  entity 
relationships,  define  how  the  data  entity  types  within  the  NPS 
enterprise  relate  to  one  another.  The  Chapter  IV  analysis 
provides  a  discussion  of  the  data  entity  type  relationships, 
listed  in  Tab  D  of  Appendix  D,  and  is  not  repeated  here. 

d.  Quantity  of  Information  Required 

The  amount  of  information  processed  by  the  various 
information  systems  that  make  up  the  current  information 
architecture  at  NPS  varies  widely.  Table  VI.  6  provides 
specific  examples,  such  as  the  number  of  records  processed, 
number  of  copies  of  an  application  required,  or  the  type  and 
frequency  of  system  use. 
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Table  VI.  6  QUANTITY  OF  INFORMATION 


Information  System 

Quantity 

student  Academic  Records  System  (STARS) 

>  1,800  student  data  records  -  quarterly  scheduling 

Banyan  Vines  Administrative  LAN 

>  875  users,  only  600  available  workstations 

Computer  Center  Backbone  Network 

295  workstations  and  100  IBM  terminals 

Minor  Property  Accountability  System 

>  15,000  minor  property  item  records 

e.  Information  User  Location 

Information  user  location  data  provides  necessary 
background  information  for  development  of  the  technical 
infrastructure.  Table  VI. 7  provides  example  user  location 
data. 


Table  VI. 7  INFORMATION  USER  LOCATIONS 


Location 

Number  of  Users 

Various  -  IN-141,  I-364E,  RO-222,  Sp-311,  BU-100 

190 

Learning  Resource  Center  -  GL-128 

34 

Learning  Resource  Center  -  GL-318 

20 

Learning  Resource  Center  -  IN-151,  IN-371 

22 

Learning  Resource  Center  -  GL-203 

35 

Learning  Resource  Center  -  R-262 

20 

f.  Information  Timeliness 

Timeliness  generally  relates  to  the  response  time 
of  data  processing  systems.  Some  types  of  information  are 
needed  immediately  while  longer  response  times  are  acceptable 
in  other  situations.  Table  VI. 8  provides  specific  examples  of 
timeliness  requirements. 
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Table  VI. 8  INFORMATION  TIMELINESS 


Information 

Timing 

Individual  student  class  schedule 

Quarterly,  approx,  one  week  before  end  of  quarter 

Individual  student  grade 

Quarterly,  approx,  one  week  after  end  of  quarter 

Base  Realignment  and  Closure  (BRAC)  data  call 

Immediately,  within  2-3  days 

Congressional  inquiry 

Immediately,  within  24  hours 

g.  Information  Format 

Information  format  drives  the  compatibility  and 
interoperability  issues,  and  applies  at  multiple  levels  of 
abstraction,  from  data  element  standardization  for 
interconnected  databases  to  common  office  automation 
application  file  formats.  Table  VI.  9  provides  examples  of 
information  format  issues. 

Table  VI.  9  INFORMATION  FORMAT 


Category 

Compatibility 

LAN  Windows  Applications 

install  Windows  on  Server  or  on  each  PC 

Download  STARS  mainframe  data  to  PC  database 

Database  and  data  element  structures 

Field  Support  Activity  (FSA)  budget  reports 

Standard  report  format 

LAN  Interconnectivity 

Standard  communications  protocols 

h.  Information  Security 

Each  information  system  at  NPS  has  both  common  and 
specific  security  requirements.  The  range  of  information  used 
in  NPS  systems  varies  from  easily  accessible  public  domain 
information  through  highly  classified  and  compartmented 
information  processed  on  secure  systems.  Table  VI. 10  provides 
a  sample  listing  of  the  common  security  requirements  for  all 
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information  systems,  derived  from  Appendix  B  of  the  NFS 
Automated  Data  Processing  Security  Program  instruction, 
NAVPGSCOLINST  5239. lA  (30  November  1992). 


Table  VI. 10  INFORMATION  SECURITY 


Requirements  Category 

Requirement 

Environmental  Requirements 

Surge  suppressors  on  all  devices 

Fire  Safety  Controls 

Automatic  smoke  or  heat  detection  equipment 

Facility  Maintenance/Cleanliness 

Prohibit  eating,  drinking,  and  smoking  in  the  vicinity 

Temperature  and  Humidity 

Follow  manufecturer's  recommended  ranges 

Water  Damage  Control 

Provide  plastic  sheets  for  susceptible  equipment 

Media  Control  and  Marking 

Permanent  operating  system  backup  copies 

Communications  Security 

Standard  Operating  Procedures  for  LANs 

Protected  Distribution  System  (PDS) 

Log  off  or  lock  unattended  terminals 

Terminal  Identification 

Use  logon  banners 

Access  Management 

Develop  and  enforce  challenge  and  escort  procedures 

Security  Software 

Configure  PCs  to  load  anti-virus  software  at  boot-up 

Security  Documentation 

Specify  security  requirements  in  LCM  documentation 

Training 

Ensure  all  users  receive  appropriate  training 

Physical  Security 

Lock  computer  spaces  at  close  of  business 

i.  Information  Prxyacy 

The  Privacy  Act  of  1974  (5  USC  552a)  levies 
specific  requirements  for  record  storage  of  information  about 
individuals.  Privacy  Act  information  about  an  individual 
includes  data  on  an  individual's  education,  financial 
transactions,  medical  history,  personal  history,  criminal 
history,  employment  history,  or  other  identifying 
characteristic,  such  as  finger  prints,  voice  prints,  or 
photographs.  Table  VI. 11  provides  examples  of  some  of  the 
requirements  identified  in  the  Navy's  directive  on 


safeguarding  personal  information  in  ADP  systems  —  SECNAVINST 
5239.1  (w/CH.  1:  May  17,  1979). 

Table  VI.  11  INFORMATION  PRIVACY 


Requirements  Category 

Requirement 

Physical  Security 

Designate  and  post  computer  areas  as  controlled  area 

Information  Management 

Label  all  output  products  and  storage  media 

Destroy  material  as  soon  as  intended  purpose  served 

Computer  System  /  Network  Security  Controls 

Control  access  through  computer  verified  passwords 

j.  Information  Accessibility 

Information  accessibility  actually  covers  a  wide 
range  of  issues,  but  is  generally  interpreted  as  the  need  to 
provide  access  to  disabled  Government  employees  or  members  of 
the  public.  This  applies  not  only  to  the  need  for  physical 
access  to  the  equipment,  but  also  the  need  to  incorporate 
appropriate  technologies  into  the  information  systems  to 
support  disabled  users.  Table  VI.  12  provides  examples  of 
accessibility  issues,  as  discussed  in  the  FIRMR  (41  CFR  201- 
20.103-7) . 

Table  VI.  12  INFORMATION  ACCESSIBILITY 

Requirement 

Equivalent  access  to  electronic  office  equipment 
Telecommunications  access  to  hearing-impaired 
Telecommunications  access  to  speech-inipaired 
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k.  Current  System  Description 


The  Chapter  IV  analysis  describes  the  current 
system,  which  in  this  case  is  the  NPS  enterprise  information 
architecture.  The  following  subsections  provide  additional 
information. 

(1)  Current  System  Users.  Table  VI.  13  categorizes 
some  of  the  current  system  users  by  system  or  application. 
The  users  listed  are  a  representative  sampling  of  the  whole 
user  population. 

Table  VI. 13  CURRENT  INFORMATION  SYSTEM  USERS 


Information  System 

Users 

student  Academic  Records  System  (STARS) 

Registrar,  Admissions,  Curricular  Offices 

Admissions  Student  Information  Database  System 

Registrar,  Admissions,  Cunicular  Offices 

Cum'cular  Officer  Student  Information  System 

Curricular  Offices,  Code  03 

Navy  Civilian  Personnel  Data  System  (NCPDS) 

Personnel  Services  -  Code  223 

(2)  Current  System  Functions.  The  Chapter  IV 
analysis  identifies  the  business  functions  supported  by  the 
various  information  systems  at  NPS.  Tabs  M  and  N  of  Appendix 
D  provide  additional  data,  including  the  functional 
decomposition  of  the  activity  hierarchy  diagram,  and  the 
activity  definition  list. 

(3)  Current  System  Workload.  Workload  analysis 
consists  of  numerous  issues,  including  growth  and 
expandability  requirements,  data  handling  or  transaction 
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processing  levels  by  type  or  volume,  and  peak  traffic  loads  by 
location.  This  research  project  does  not  provide  any  workload 
analysis . 

(4)  Current  System  Costs.  System  costs  include 
not  only  the  acquisition  costs  of  the  hardware,  software,  and 
installation,  but  also  all  the  life  cycle  costs,  including 
operator  salaries,  training,  maintenance,  etc.  Table  VI.  14 
provides  a  sample  listing  of  acquisition  costs  for  new  systems 
as  proposed  by  various  organizational  units  in  their  fiscal 
year  (FY)  1994  IS  budget  submissions.  The  table  includes 
examples  of  life  cycle  costs  where  available. 

(5)  Current  System  Inventory.  NPS  is  currently 
conducting  a  inventory  of  all  automated  data  processing  (ADP) 
equipment  in  conjunction  with  the  NPS  Minor  Property  triennial 
inventory.  No  consolidated  list  of  equipment  exists;  each 
organizational  unit  is  responsible  for  maintaining  an 
inventory  of  ADP  equipment  in  their  custody.  No  attempt  was 
made  to  evaluate  the  system  components  or  adequacy  of  program 
and  system  documentation. 

1.  Current  System  Performance  Evaluation 

The  performance  of  the  current  information 
architecture  is  a  function  of  the  technical  infrastructure. 
In  the  current  enterprise  configuration  of  multiple 
independent  systems,  performance  can  only  be  evaluated  through 
evaluations  of  each  component,  such  as  mainframe  applications. 
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Table  VI. 14  INFORMATION  SYSTEM  COSTS 


System  or  Project  Name 

Estimated  Costs 

Dean  of  Faculty  Centralized  Maintenance 

Contractor  provided  hardware  support:  125,000 

Contractor  provided  software  support:  125,000 

In-house  and  one-time  reoairs:  100.000 

Total:  $  350,000 

System  Management  Program  Support  System 

Hardware:  250,000 

Software:  70,000 

Supplies/Other:  50.000 

Total:  $  370,000 

Aeronautics  and  Astronautics  Computational  Facility 

$  349.000 

Distance  Learning  Resource  Center 

$  225,000 

Computing  &  Network  Services  (Computer  Center) 

Procurement:  343,800 

Operating  Costs:  656.000 

Total:  $  999,800 

Computer  Science  Department  Laboratories 

$  900,000 

Defense  Resources  Management  Institute  System 

Hardware:  120,500 

Software:  20,000 

Supplies:  20,000 

Maintenance:  5.000 

Total:  $  165,500 

ECE  Department  Academic  Computing  Facility 

$  503,000 

Library  Automation  System 

Procurement:  124,500 

Operating  Costs:  191.000 

Total:  $  315,500 

Math  Department  Distributed  Computer  Facilities 

$  70,000 

ME  Department  Distributed  Computer  Facilities 

Hardware:  961,000 

Software:  75,000 

Supplies:  34,000 

Maintenance:  15.000 

Total:  $  1,085.000 

Meteorology  Department  Computing 

$  245,000 

Information  System  Support  (MIS) 

Hardware:  117,000 

Software:  22,000 

Supplies:  5,000 

Maintenance:  112.000 

Total:  $  256,000 

Joint  Deployable  Intelligence  Support  System  (JDISS) 

$  132,000 

NSA  Teaching,  Research  and  Admin  Systems 

Hardware:  193,400 

Software:  49 ,000 

Supplies/Other:  17.000 

Total:  $  259,400 

Oceanography  Computer  Systems 

$  271,000 

Physics  Department  Computer  Facilities 

$  400,000 

Space  Systems  Computing  Facilities 

$  146,000 

NPS  Systems  Technology  Laboratory 

$  762,000 
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or  LAN  applications.  No  attempt  is  made  in  this  project  to 
conduct  performance  evaluations  for  the  systems  and  components 
in  the  current  architecture. 

2 .  System  Life 

Based  on  the  requirements  for  five-year  strategic 
planning  found  in  multiple  governing  directives,  the  "system 
life"  for  the  next  information  architecture  is  arbitrarily 
projected  to  be  60  months. 

3 .  Description  of  Requirements 

The  analysis  of  the  information  needs  and 
requirements,  and  the  evaluation  of  the  current  information 
architecture  (albeit  at  a  high  level)  leads  to  the  following 
discussion  of  the  NFS  data  management  requirements: 

a.  Basis  for  Reqair&nents 

The  basis  for  the  requirements  is  support  for  the 
NFS  mission.  Chapter  IV  provides  a  discussion  of  the  NFS 
mission,  the  strategic  vision,  and  other  objectives  and  goals; 
that  discussion  is  not  repeated  here. 

(1)  Deficiencies  in  Existing  Capabilities.  The 
primary  deficiency  in  the  existing  capabilities  of  information 
systems  throughout  the  NFS  enterprise  is  the  inability  to 
support  management  with  timely  information.  This  deficiency 
exists  due  to  the  decentralized  nature  of  information  systems 
management,  and  the  related  data  management.  Most  information 
needed  by  NFS  managers  is  often  already  available  in  some 
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system  within  the  NPS  enterprise;  however,  the  manager  does 
not  have  direct,  immediate  access  to  that  information. 

This  information  access  problem  has  three 
aspects:  first,  the  manager  needs  information,  not  just  data; 
second,  the  manager  needs  the  information  in  a  timely  manner; 
and  third,  the  data  or  information  may  exist  in  multiple 
sources.  The  issue  of  information  versus  data  generally 
refers  to  the  manager's  need  for  a  more  abstract  or  aggregated 
view  of  the  underlying  data;  i.e.,  the  manager  does  not  want 
to  count  all  the  elements  in  the  data  report  just  to  get  the 
total  sum.  The  issue  of  timely  information  refers  to  the 
manager's  desire  to  have  direct  and  immediate  access  to  the 
information;  i.e.,  the  manager  does  not  have  to  place  a 
priority  request  to  the  keeper  of  the  data  and  hope  for  a 
timely  response.  The  issue  of  multiple  sources  for  data 
needed  by  a  manager  is  not  easily  overcome,  however,  solutions 
to  this  data  access  problem  exist:  the  data  may  be  stored  in 
a  central  location,  multiple  copies  of  the  data  may  be 
distributed  throughout  the  enterprise,  or  specialized  data 
access  tools  may  be  used  to  retrieve  the  data  from  wherever  it 
is  distributively  stored.  Key  to  the  resolution  of  all  these 
issues  is  providing  interconnectivity  among  all  the  enterprise 
information  systems,  interoperability  among  systems  and 
applications,  and  standardization  of  the  corporate  data. 
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(2)  New  or  Changed  Program  Requirements .  The  NPS 
mission  is  not  likely  to  change;  the  focus  remains  on 
providing  students  with  a  quality  education,  and  conducting 
leading-edge  technology  research  to  support  the  Navy. 
However,  as  additional  educational  requirements  emerge,  NPS 
develops  new  academic  programs  to  meet  these  demands.  As 
technology  evolves,  new  research  ideas  develop  and  require 
further  study.  These  evolving  requirements  cause  changes  to 
business  functions,  and  lead  to  a  revision  of  the  information 
architecture. 

One  example  of  a  new  trend  in  industry  which 
is  also  beginning  to  develop  at  NPS  is  automated  support  for 
group  or  team  projects.  This  automated  support  ranges  from  a 
simple  capability  to  communicate  among  all  the  group  members 
through  electronic  mail  to  the  use  of  group  decision  support 
systems  and  two-way  video-teleconferencing  systems.  Data  and 
information  management  in  such  an  environment  presents 
additional  complexities,  and  drives  the  NPS  enterprise's 
information  architecture  and  underlying  infrastructure  towards 
more  capable  and  complex  system  structures. 

(3)  Increased  Economy  and  Efficiency.  The 
downsizing  of  the  military  forces  and  the  supporting  defense 
industry  infrastructure  as  a  result  of  the  changing  global 
environment  has  led  to  declining  budgets  for  all 
organizations.  This  decreased  funding  drives  an 
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organization's  desires  to  economize  and  improve  efficiency 
wherever  possible.  Efforts  in  this  area  at  NFS  include 
actions  underway  as  part  of  being  designated  a  "Government 
Reinvention  Laboratory",  and  actions  supported  by  the 
implementation  of  Total  Quality  Leadership  (TQL) .  Another  key 
driver  for  the  NFS  enterprise  is  the  need  to  show  Congress  and 
the  Base  Realignment  and  Closure  (BRAC)  Committee  that  the  NFS 
is  a  unique  institution,  more  efficient  and  effective  in  the 
accomplishment  of  its  mission  than  any  other  comparable 
civilian  or  military  educational  institution. 

Automating  business  processes  frequently 
improves  efficiency  and  economy,  but  only  if  the  business 
process  is  efficient  and  economical  in  the  first  place.  The 
information  architecture  analysis  provides  a  means  to  examine 
business  functions,  and  determine  if  more  efficient  and 
economical  processes  exist. 

Jb.  Functional  Requiraments 

The  functional  requirements  for  the  data 
management  aspects  of  any  information  architecture  are 
directly  connected  to  the  functional  requirements  of  the 
underlying  technical  infrastructure,  including  the  network 
connectivity.  The  functional  requirements  are  briefly  stated 
as  the  ability  for  any  authorized  user  to  access  any  NFS 
enterprise  information  from  any  location,  i.e.,  the 


162 


requirement  exists  for  a  fully  interconnected  and 

interoperable  network,  using  standardized  data  structures. 

c .  Applicable  Standards 

No  specific  standards  for  an  information 
architecture  exist,  therefore  none  are  specified  here. 
However,  many  higher  level  directives  provide  guidance  on  data 
standardization,  system  language  specification,  and  other 
areas  that  are  applicable  to  the  implementation  of  data 
management  strategies.  Chapter  II  provides  an  overview  of 
these  directives;  no  further  discussion  is  provided  here. 

4.  Conpatibility-Limited  Requirements 

There  are  no  enterprise-wide  compatibility-limited 
requirements  (as  defined  by  the  FIRMR) .  Currently  available 
technology  satisfies  all  the  requirements  for  system 
interoperability  and  compatibility.  However,  use  of  equipment 
that  is  directly  compatible  with  existing  system  equipment 
leads  to  performance  improvements. 

5 .  Justification  for  Make  and  Model 

Likewise,  there  are  no  enterprise-wide  "make  and 
model"  restrictive  requirements  (as  defined  by  the  FIRMR) . 
Currently  available  and  projected  future  technology  satisfies 
all  the  requirements  for  system  interoperability  and 
compatibility.  However,  use  of  specific  make  and  model 
equipment  may  be  desirable  from  a  training  learning  curve 
perspective . 
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6 .  Security  Requirements 

Security  requirements  are  specified  in  the  NPS 
Automated  Data  Processing  (ADP)  Security  Program  instruction, 
NAVPGSCOLINST  5239. lA  (30  November  1992),  and  are  not  repeated 
here . 

7 .  Accessibility  Requirements  for  Individuals  with 

Disabilities 

This  project  does  not  address  specific  accessibility 
requirements . 

8 .  Space  and  Environmental  Requirements 

Space  and  environmental  requirements  are  a  function  of 
the  technical  infrastructure,  and  are  not  addressed  in  this 
project. 

9.  Workload  and  Related  Requirements 

This  project  does  not  address  workload  requirements. 

10 .  Records  Management  Requirements 

This  project  does  not  address  records  management 
requirements . 

B.  ANALYSIS  OF  NPS  DATA  MT^AGEMENT  ARCHITECTURE  ALTERNATIVES 

Chapter  V  identifies  the  alternative  architectures 
resulting  from  the  market  surveys;  this  section  addresses 
those  alternatives  in  terms  of  meeting  the  identified  NPS 
information  architecture  requirements.  As  with  the 
requirements  analysis,  this  analysis  of  alternatives  does  not 


164 


conform  to  the  guidance  in  the  FIRMR  and  GSA  guide,  but 
attempts  to  include  all  areas  of  discussion. 

1.  Consideration  of  Alternatives 

GSA's  mandatory-for-use  and  mandatory- for- 
consideration  programs  do  not  address  information 
architectures,  and  therefore  are  not  investigated.  However, 
these  programs  apply  to  any  implementation  of  an  alternative 
information  architecture,  since  the  programs  provide  equipment 
for  meeting  the  supporting  technologies  and  infrastructure 
requirements . 

2.  Cost  for  Each  Alternative 

The  choice  of  an  alternative  determines  which  cost 
analysis  method  to  use  —  simple  cost/benefit  analysis  or  net 
present  value  of  life-cycle  costs  analysis  —  since  the  cost 
of  some  alternatives  may  be  less  than  the  $50,  000  expected 
cost  threshold.  The  proper  implementation  of  any  alternative 
concept  investigated  here  quickly  drives  the  costs  over  the 
threshold,  and  thus  forces  a  full  life-cycle  cost  evaluation. 

The  vendor-specific  implementation  of  each  alternative 
determines  the  majority  of  the  costs  associated  with  each 
alternative.  Additionally,  analysis  of  non-cost  functional 
and  risk  factors  requires  the  use  of  a  vendor-specific 
implementation  of  each  alternative  with  its  supporting 
technological  infrastructure.  Therefore,  no  precise  cost 
estimates  exist  in  this  analysis  for  each  alternative. 
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The  majority  of  recent  industry  data  addresses  the 
costs  associated  with  client/server  implementations. 
Client/ server  architectures  are  the  current  technological 
answer  to  the  information  processing  issues  raised  by 
corporate  downsizing  of  rightsizing.  One  study  by  the  Datapro 
Information  Services  Group  (1994)  provides  a  relative 
assignment  of  client/server  technology-related  costs,  shown  in 
Table  VI. 15. 


Table  VI. 15  CLIENT/SERVER  TECHNOLOGY-RELATED  COSTS 


Technology 

Implementation 

Cost 

Training  Cost 

Client/  Server  Hardware 

45  % 

05  % 

Databases 

22  % 

14  % 

Development  Tools 

21  % 

29  % 

Application  Software 

30  % 

30  % 

Network  Software 

19  % 

12  % 

Operating  System 

13  % 

11  % 

Consulting  Services 

17  % 

14  % 

Ellen  Hufnagel  (1994,  p.  28)  provides  two  strategies 
for  rapidly  assessing  probable  client/server  implementation 
costs.  The  first  strategy  is  a  very  simple  "ballpark" 
approach:  the  number  of  potential  end-users  is  multiplied  by 
one  of  the  following  system  costs: 

1.  "Bare-bones"  system  —  $  31,500 

2.  Middle-of-the-road  system  —  $  42,500 

3.  Full  bells  and  whistles  system  —  $  51,500 

Using  these  values,  installation  of  a  600  user  middle-of-the- 
road  client/server  system  to  replace  the  NFS  Banyan  Vines 


166 


administrative  LAN  would  cost  approximately  $25. 5M,  or  over 
two-and-a-half  times  the  estimated  total  NFS  IS  annual  funding 
level . 

The  second  strategy  is  a  more  detailed  fill-in-the- 
blanks  approach,  and  consists  of  two  parts:  identifiable  or 
quantifiable  costs,  and  hidden  or  unquant ifiable  costs.  Table 
VI. 16  provides  a  cost  breakdown  of  the  second  strategy. 

Table  VI. 16  ASSESSING  CLIENT/SERVER  COSTS 


Identifiable/Quanttfiable  Costs 

Hidden/Unquantifiable  Costs 

Hardware 

System  Administration 

Client  -  estimate  $  8,000  to  $  15,000  per  end  user 

Estimate  $  500  to  $  700  per  client  per  month 

Server  —  estimate  $  25,000  to  $  1 10,000  per  20  users 

Training 

Networks 

Application  coders  w/o  experience  -  $  3,500  each 

Routers  —  varying  costs,  assume  most  expensive 

Application  coders  w/  experience  -  $  1 ,500  each 

LAN  —  installation  charges 

Users  —  $  1 ,000  each 

External  -  carrier  costs  and  costs  of  redundancy 

Mahtenance  and  Software  Upgrades 

Software 

Estimate  10  %  of  hardware/software  purchase  price 

Operating  Systems  -  10  %  annually  for  maintenance 

Middleware  —  10  products  X  $  50,000  to  $  250,000  ea 

Consulting  Fees 

In-House  Application  Deveiopment 

Estimate  $  145  to  $  195  per  hour 

Estimate  $  35  to  $  65  per  project  hour 

The  second  strategy  does  not  provide  a  complete  listing  of 
costs  since  many  of  these  costs  are  related  to  vendor-specific 
implementations  (routers,  LAN  installation,  etc.);  therefore, 
a  comparison  of  the  costs  determined  from  the  two  strategies 
is  not  possible. 

3 .  Conversion  Analysis 

Selection  of  any  alternative  results  in  conversion 
requirements;  the  extent  of  conversion  required  differs 
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significantly.  A  brief  description  of  the  types  of  conversion 
issues  associated  with  each  alternative  follows.  This 
conversion  analysis  does  not  address  costs,  risks,  or  size  of 
conversion;  that  requires  a  more  detailed  analysis  of  the 
current  information  architecture  and  all  the  supporting 
infrastructure  technologies. 

Conversion  to  a  distributed  processing  information 
architecture  requires  true  data  management,  including 
determination  of  physical  database  locations,  data  access 
methods,  two-phase  commit  and  synchronization  procedures  for 
the  distributed  databases,  replication  timing  decisions,  and 
a  host  of  other  issues.  True  distributed  computing  is  still 
in  its  infancy  throughout  industry,  primarily  due  to  the  lack 
of  adequate  industry  standards. 

Conversion  to  a  client/server  processing  information 
architecture,  using  the  current  mainframe  as  a  server, 
requires  addition  of  communications  processors  to  interface 
with  the  network  of  clients,  high  speed  printers  for  reports, 
adequate  data  storage  and  data  backup  capabilities,  and 
gateways  (middleware)  to  provide  database  interoperability  and 
character  coding  language  translation. 

Conversion  to  a  client/server  processing  information 
architecture,  using  dedicated  servers,  requires  as  a  minimum 
the  selection  of  appropriate  servers,  based  in  part  on  the 
server's  operating  system;  selection  of  appropriate  client 
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workstations;  porting  or  redesigning  applications  to  the  new 
environment,  and  training  of  users  and  technicians. 

Conversion  to  an  information  architecture  that  uses  a 
data  warehouse  requires  selection  of  a  relational  DBMS  for  the 
warehouse,  selection  of  a  data  warehousing  tool  to  provide  the 
data  extraction  and  aggregation  services,  and  selection  of  a 
data  access  tool  to  retrieve  the  data  from  the  data  warehouse 
for  analysis. 

Conversion  to  an  information  architecture  that  simply 
uses  data  access  tools  as  front  ends  first  requires  selection 
of  a  data  access  tool  robust  enough  to  interface  between 
multiple  front-end  hardware  platforms  and  multiple  back-end 
databases.  Additional  requirements  include  enabling  full 
interconnectivity  between  systems,  i.e.,  establishing  an 
adequate  technical  infrastructure;  and  conducting  training  for 
users  and  technicians. 

4 .  Obsolescence  Analysis 

Due  to  the  rapid  pace  of  technological  change  within 
the  computer  industry,  and  the  rapid  rise  and  fall  of  many 
vendors,  the  process  of  predicting  obsolescence  is  very 
difficult.  The  concepts  identified  as  possible  alternatives 
for  an  information  architecture  are  technologically  stable. 
However,  vendor-specific  implementations  of  each  concept 
change  frequently  as  new  standards  and  vendor  alliances  are 
created.  Selection  of  any  of  the  listed  alternatives  provides 
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a  data  management  architecture  which  will  remain  viable  for 
the  projected  lifetime  duration. 

5 .  Capability  and  Performance  Validation 

As  discussed  in  Appendix  F,  the  FIRMR  allows  each 
organization  to  select  the  methods  to  be  used  for  capability 
and  performance  validations. 

a.  Capability  Validation 

The  description  of  each  data  management 
alternative  provided  in  Chapter  V  addresses  only  the  concept, 
not  the  actual  implementation  by  any  particular  vendor  or  set 
of  vendors.  Therefore,  the  method  chosen  for  capability 
validation  is  examination  of  the  technical  literature, 
supplemented  by  vendor  certification  of  conformance  with 
functional  requirements.  Vendors  willingly  provide  extensive 
information  related  to  their  products,  ranging  from  glossy 
sales  brochures  to  very  technical  literature,  including  white 
papers  and  independent  analyses  of  the  vendor's  products.  In 
some  cases,  vendors  provide  free  seminars  and  hands-on 
demonstrations  of  their  products.  Review  of  the  available 
technical  literature,  and  attendance  at  numerous  trade 
exhibitions  and  vendor  seminars,  provides  this  researcher 
sufficient  technical  background  to  perform  a  conceptual 
capability  validation. 

Using  these  methods,  only  the  data  warehouse 
alternative  fails  to  meet  all  the  functional  requirements. 
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Current  data  warehouses  (and  data  warehouse  tools)  store 
aggregate  operational  and  other  data  for  use  in  organizational 
Decision  Support  Systems  (DSS)  or  Executive  Information 
Systems  (EIS) ,  but  do  not  provide  a  good  capability  to  readily 
access  discrete  data.  Therefore  a  data  warehouse  is  not 
recommended  as  the  sole  method  of  data  management;  however, 
use  of  a  data  warehouse  does  provide  significantly  improved 
access  to  common  corporate  data.  Discussions  with  vendor 
representatives  and  system  integration  specialists  reveals 
that  industry  is  investigating  better  methods  to  access  and 
use  the  information  stored  in  a  data  warehouse,  but  no 
specific  methods  have  been  identified  to  date  (Haderle,  1994) . 
jb.  Performance  Validation 

Performance  validation  applies  only  to  specific 
implementations  of  each  generic  alternative,  not  to  the 
conceptual  alternative  itself.  Since  this  analysis  did  not 
examine  specific  implementations,  no  performance  validations 
were  conducted. 

6.  Overall  Data  Management  Architecture  Conclusions 

Four  of  the  five  alternatives  discussed  provide  the 
required  ability  for  an  authorized  user  to  access  any  NPS 
enterprise  information  from  any  location;  the  exception  is  the 
data  warehouse  as  discussed  in  the  previous  section.  Each 
alternative  has  advantages  and  disadvantages. 
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The  overriding  disadvantage  of  the  fully  distributed 
processing  information  architecture  is  the  lack  of 
technological  maturity  within  the  technical  infrastructure  and 
lack  of  industry  standards.  These  disadvantages  will  remain 
for  the  duration  of  the  projected  lifetime  (five  years),  but 
will  disappear  as  the  standards  are  accepted  throughout 
industry. 

The  primary  disadvantage  to  a  client/server  processing 
information  architecture  is  the  high  initial  cost  of 
conversion  of  the  technical  infrastructure;  these  costs 
i^^lude  the  costs  of  establishing  a  network  that  provides  the 
required  interconnectivity,  the  costs  of  porting  all  the 
applications  to  the  new  platforms  and  operating  systems,  and 
the  costs  of  standardizing  (converting)  the  data  to  a  common 
format.  The  principal  advantage  is  the  degree  of  industry 
support  for  the  client/server  information  processing  concept, 
with  numerous  vendors  providing  a  wide  range  of  client/server- 
related  products,  scalable  up  to  multiple  massively  parallel 
processing  systems. 

A  data  warehouse  conceptually  provides  access  to  vast 
amounts  of  corporate  data;  however,  not  all  the  NPS  enterprise 
data  belongs  in  a  data  warehouse.  Therefore,  this  solution 
provides  at  best  only  a  partial  solution  for  data  management 
at  NPS. 

The  use  of  data  access  tools  or  other  middleware  is  a 
stopgap  solution,  which  only  postpones  the  inevitable 
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conversion  to  a  more  distributed  processing  environment.  As 
such,  the  use  of  middleware  has  a  strong  role  as  a  transition 
mechanism  to  a  client/server  or  other  form  of  distributed 
information  processing  architecture.  Selection  of  an 
appropriate  middleware  tool  provides  a  means  to  provide 
continued  or  parallel  access  to  corporate  data  during  the 
migration  to  a  more  distributed  information  processing 
architecture . 

C .  CHAPTER  SUMMARY 

This  chapter  provides  discussion  in  two  areas:  an  analysis 
of  the  NPS  information  architecture  requirements,  using  a 
loose  application  of  the  FIRMR's  analytical  methods  (described 
in  Appendix  F)  ;  and  an  analysis  of  the  data  management 
alternatives,  again  using  a  loose  application  of  the  FIRMR's 
analytical  methods  (also  described  in  Appendix  F) . 

The  next  chapter  provides  the  actual  conclusions  and 
recommendations  as  a  result  of  combining  these  two  analyses 
with  the  NPS  enterprise  and  information  architecture  analyses 
of  Chapter  IV. 
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VII.  THESIS  CONCLUSION  AND  RECOMMENDATIONS 

This  chapter  provides  the  author’s  conclusions  and 
recommendations  in  four  areas:  a  data  management  architecture 
for  the  NPS  enterprise  in  light  of  resource  constraints;  the 
study  underway  by  the  Provost's  Committee  on  NPS  Mission 
Organization;  use  of  the  information  engineering  methodology 
and  the  lEF™  CASE  tool;  and  follow-on  study  and  analysis 
efforts . 

A.  DATA  MANAGEMENT  ARCHITECTURE  FOR  NPS 

This  section  provides  the  recommendations  for  a  data 
management  architecture  resulting  from  the  analyses  of  the  NPS 
enterprise  information  architecture  in  Chapter  IV,  the  NPS 
information  needs  in  Chapter  VI,  and  the  available  data 
management  architecture  alternatives  in  Chapter  V.  The  author 
cautions  the  reader  to  keep  in  mind  the  following:  the  high- 
level  overview  nature  of  the  analyses  conducted  does  not 
provide  the  normal  full  justification  required  for  the  actual 
selection  of  any  data  management  architecture  alternative;  the 
author's  conclusions  and  recommendations  simply  provide  a  hint 
of  a  strategic  direction  or  path  for  NPS  to  pursue  based  on 
the  author's  research  and  analysis  results. 
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1.  Data  Management  Architecture  Conclusions 


The  available  financial  and  personnel  resources, 
discussed  in  Chapter  IV,  do  not  support  immediate 
implementation  of  the  data  management  architecture 
recommendations,  unless  funding  is  reprogrammed  and  additional 
personnel  become  available.  One  solution  to  the  funding 
problem  is  distribution  of  the  transition  planning  phase  tasks 
as  collateral  assignments  to  personnel  involved  with  the 
various  existing  departmental  information  system  projects. 
Another  solution  is  incorporation  of  the  desired  data 
management  architecture  into  an  existing  departmental 
information  system  project  as  a  pilot  program  for  testing  and 
evaluation,  before  expanding  to  the  entire  enterprise. 

The  discussion  of  the  recommendations  does  not  address 
the  many  related  issues  associated  with  the  implementation  of 
the  data  management  architecture  alternative,  such  as 
conversion  costs,  hardware  and  software  requirements,  and 
personnel  training  requirements.  These  issues  depend  on 
vendor-specific  implementations,  and  are  not  addressed  here. 

2.  Data  Management  Architecture  Recommendations 

Inclement  an  enterprise-wide  client/ server  information 
processing  architecture.  Client/server  technology  does  not 
provide  all  the  functionality  of  a  fully-distributed 
information  processing  system;  however,  unlike  distributed 
processing  technology,  the  client/server  technology  is  mature 
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and  relatively  stable.  Multiple  vendors  provide  scalable 
client/server  implementation  solutions  that  meet  or  exceed  the 
NPS  enterprise  needs  and  requirements.  Therefore,  a 
client/server  data  management  and  information  processing 
architecture  is  the  recommended  choice. 

The  implementation  of  a  client/server  data  management 
and  information  processing  architecture  will  not  occur  all  at 
once;  several  phases  exist  in  the  transition  path. 
Implementation  of  an  enterprise-wide  client/server 
architecture  requires  a  significant  underlying  technical 
infrastructure.  The  existence  of  an  adequate  network 
infrastructure  is  an  implicit  and  explicit  prerequisite  to  the 
use  of  a  client/server  architecture.  Interconnectivity  and 
interoperability  throughout  the  enterprise  is  necessary  to 
provide  any  (authorized)  user  with  the  ability  to  obtain  data 
from  any  data  location.  Therefore,  the  technical  network 
infrastructure  must  first  be  put  into  place. 

System  performance  requirements  dictate  the  eventual 
migration  to  a  single  database  management  system.  The  actual 
choice  of  a  specific  DBMS  is  a  vendor-specific  implementation 
issue,  which  is  not  addressed  here.  The  migration  to  a  single 
specific  DBMS  includes  a  transition  period  of  undetermined 
duration.  During  this  transition  phase,  multiple  DBMS  and 
multiple  databases  exist  until  the  data  can  be  converted  to 
the  new  DBMS’  database  format.  Middleware  data  access  tools 
provide  the  means  to  maintain  access  to  legacy  data  in  the 
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multiple  different  databases  until  the  data  conversion  is 
complete.  Therefore,  selection  and  use  of  an  appropriate 
middleware  data  access  tool  is  critical  to  the  successful 
implementation  of  the  client/server  architecture.  It  is 
important  to  note  that  the  use  of  multiple  types  of  DBMSs 
linked  through  an  appropriate  middleware  data  access  tool  only 
provides  a  short-term  solution,  since  the  overhead  induced  by 
the  middleware  prevents  the  system  from  meeting  performance 
requirements . 

The  selection  of  the  specific  DBMS  to  be  used  often 
drives  the  selection  of  server  hardware  platforms. 
Occasionally,  a  desire  to  use  an  existing  hardware  platform 
for  a  server,  such  as  a  mainframe  computer,  will  drive  the 
decision  of  which  DBMS  to  use.  DBMS  vendors  continue  to 
expand  the  portability  of  their  systems  to  include 
interoperability  with  multiple  hardware  vendors  and  multiple 
operating  systems.  Eventually  the  selection  of  a  particular 
server  hardware  platform  will  depend  solely  on  performance 
characteristics.  For  NFS,  use  of  the  mainframe  computer  as  a 
high  storage  capacity  database  server  provides  a  means  to  more 
fully  utilize  the  mainframe's  capabilities  while  transitioning 
to  a  distributed  network  of  dedicated  database  servers. 

Conversion  of  data  to  a  single  DBMS  database  structure 
also  provides  an  opportunity  to  fully  implement  data  element 
standardization  throughout  the  NFS  enterprise.  The  transition 
phase  supports  parallel  data  element  standardization  efforts 
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by  departmental  data  managers  to  minimize  the  length  of  the 
transition.  A  common  enterprise-wide  data  dictionary  results 
from  the  coordinated  standardization  efforts  of  all  data  users 
and  managers . 


B.  NPS  MISSION  ORGANIZATION  STUDY  RECOMMENDATIONS 

As  previously  mentioned  in  Chapter  IV,  the  timing  of  this 
project  report  coincides  with  an  effort  by  the 
Provost/Academic  Dean  to  determine  whether  or  not  structural 
changes  are  required  for  the  NPS  organization.  A  summary  of 
the  author's  recommendations  regarding  this  study  follow: 

1.  Divide  the  overlapping  functions  of  the  Dean  of  Faculty 
(Code  07)  and  the  Dean  of  Instruction  (Code  06)  between 
the  two  offices.  The  Dean  of  Faculty  functions  relate  to 
personnel  issues;  the  Dean  of  Instruction  functions 
relate  to  academic  issues. 

2.  Shift  the  Dean  of  Students/Director  of  Programs  military 
coordination  of  curricular  programs  and  curricular  review 
functions  to  the  Dean  of  Instruction.  Shift  the  Dean  of 
Students/Director  of  Programs  military  faculty  selection 
function  to  the  Dean  of  Faculty. 

3.  Maintain  the  Dean  of  Research  (Code  08)  position. 

4.  The  overlapping  functions  of  Deans  in  the  matrix 
organization  hinder  effectiveness  and  efficiency,  and 
should  be  eliminated. 

5.  A  proposed  solution  for  the  Code  05  dilemma  is  a  central 
organization  combining  the  functions  of  Computer  Services 
and  Information  Services,  headed  by  a  professional, 
experienced  Corporate  Information  Officer  reporting 
directly  to  the  Superintendent.  The  central  organization 
responsibilities  include  all  common  infrastructure 
issues;  every  department/code  provides  operation  and 
maintenance  for  their  specific  systems,  coordinated 
through  the  central  organization. 
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6.  The  functions  performed  by  the  Assistant  to  the  Provost 
duplicate  the  functions  performed  (or  assigned)  to 
niomerous  other  organizational  codes  at  NPS.  Restoration 
of  all  these  functions  to  their  assigned  codes  has  the 
potential  to  significantly  reduce  the  amount  of 
duplicative  and  unproductive  effort;  key  to  this  shift  of 
responsibilities  is  the  improvement  of  management 
information  access  for  the  Provost/Academic  Dean. 

7.  Responsibility  assignments  for  specific  functions  are: 
The  Dean  of  Instruction  for  new  instructional  programs; 
the  Dean  of  Research  for  new  research  centers;  the  Dean 
of  Instruction  for  new  instructional  laboratories;  the 
Dean  of  Computer  and  Information  Services  for  distance 
learning  facilities;  the  Director  of  Programs  for 
international  programs. 

Chapter  IV  provides  the  full  discussion  of  the  author's 
conclusions  and  recommendations  regarding  this  study. 


C.  EVALUATION  OF  INFORMATION  ENGINEERING  AND  lEF  ™ 

This  section  provides  the  author's  evaluation  of  the 
information  engineering  methodology  as  an  analysis  approach, 
and  the  effectiveness  of  the  automated  implementation  of  the 
information  engineering  methodology  in  the  TI  lEF™  CASE  tool. 

1.  Information  Engineering  Methodology  Evaluation 

The  information  engineering  methodology  provides  an 
effective  tool  to  analyze  an  organization,  develop  an 
information  architecture,  and  even  design  and  implement 
information  systems  to  support  an  organization's  business 
areas.  The  data-oriented  premise  of  the  methodology  approach 
provides  information  engineering  with  its  greatest  strength: 
the  stability  of  the  generated  data  models.  Another  strength 
is  the  methodology's  flexibility  during  the  early  phases  — 
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numerous  alternative  methods  exist  for  obtaining  the 
organization's  policies,  objectives,  and  strategies. 

Zeiders  (1990,  p.  32)  cites  the  requirement  for 
significant  upfront  user  involvement  as  a  potential  weakness 
to  the  use  of  information  engineering.  User  involvement  is 
really  a  function  of  the  specific  application  development 
scenario,  not  necessarily  of  the  methodology  itself. 

The  principal  advantage  that  the  information 
engineering  methodology  has  over  any  other  methodology  is  the 
support  over  the  entire  systems  lifecycle,  from  strategic 
planning  to  full  systems  implementation.  Therefore,  the 
author's  analysis  serves  as  a  basis  for  future  system 
developments,  and  can  be  integrated  into  the  lifecycle. 

2 .  lEF™  CASE  Tool  Evaluation 

The  lEF™  has  significant  capabilities  as  an  integrated 
CASE  tool.  This  project  did  not  use  the  full  capabilities  of 
the  CASE  tool,  and  thus  encountered  significant  limitations. 
The  heart  of  the  lEF™  CASE  tool  is  the  Central  Encyclopedia, 
which  resides  on  a  mainframe  computer,  and  is  accessed  through 
the  individual  user  workstations.  The  lEF™  tool  set  used  for 
this  project  did  not  include  the  mainframe  component  (not 
available  at  this  site)  ,  and  thus  did  not  use  the  Central 
Encyclopedia  capabilities;  a  single  workstation  contains  all 
the  toolsets  available  for  the  project. 
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The  lack  of  a  Central  Encyclopedia  prevents  integrated 
version  control.  An  analyst  can  not  integrate  specific 
models,  such  as  the  data  model  or  the  activity  model,  derived 
from  multiple  versions  of  the  overall  organization  model. 
Therefore,  when  an  analyst  follows  one  approach  and  reaches  a 
dead  end  (as  this  author  did  on  several  occasions) ,  there  is 
no  graceful  recovery  method.  The  analyst  uses  a  copy  (if 
made)  of  an  earlier  version  as  a  baseline,  and  all  the  correct 
unrelated  data  is  re-entered  into  the  model,  or  else  the  model 
is  recreated  from  the  beginning.  A  Central  Encyclopedia 
maintains  multiple  versions  of  the  same  model,  and  allows  a 
user  to  select  portions  from  each  version  to  create  another 
version,  negating  the  need  to  start  over  again.  The  lack  of 
a  Central  Encyclopedia  is  a  significant  limitation. 

Chapter  IV  discusses  nximerous  analysis  artificialities 
due  to  limitations  of  the  CASE  tool.  A  summary  of  these  and 
other  limitations  follows: 

1.  The  Organizational  Hierarchy  Diagram  (OHD)  tool  does  not 
provide  the  capability  to  diagram  organizational  support 
functions  (i.e.,  organizational  units  that  provide 
support  to  multiple  other  units  in  the  hierarchy)  or 
matrix  organizational  structures,  such  as  NFS' 
organization.  Only  tree-like  hierarchies  are  supported. 

2.  Matrices  used  to  describe  the  interrelationships  between 
business  functions  and  other  planning  objects  do  not 
include  all  the  defined  functions  in  the  Activity 
Hierarchy  Diagram  (AHD) .  Only  the  lowest  level  function 
in  any  individual  decomposition  within  the  overall 
hierarchy  is  included.  This  limitation  prevents 
evaluation  of  numerous  functions  that  may  decompose 
through  multiple  levels  before  reaching  the  lowest  level. 
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3.  Similar  to  the  problem  with  functions  in  matrices,  data 
entity  subtypes  are  not  represented  in  matrices.  This 
prevents  the  evaluation  of  any  data  entity  subtype, 
significantly  limiting  the  level  of  detail  in  an 
analysis . 

4.  Definitions  of  the  relationships  between  data  entities 
are  not  movable,  i.e.,  if  a  change  is  made  to  a  data 
model  that  results  in  partitioning  a  data  entity  into 
subtypes,  the  relationships  can  not  be  moved  to 
correspond  with  the  particular  subtype;  relationships 
must  be  deleted  and  recreated  at  the  appropriate 
locations . 

5.  Matrices  which  define  the  interrelationships  between 
functions/processes  and  data  entities,  or  organizational 
units ^  and  data  entities  limit  the  description  of  the 
relationship  to  a  single  code  from  the  four  available 
codes:  Create,  Read,  Update,  Delete.  This  prevents  a 
full  detailed  description  of  the  actual  relationship. 

6.  Data  entry  in  the  various  specific  toolsets  is  a  tedious 
and  time-consuming  process,  and  methods  to  allow  more 
rapid  data  entry  would  significantly  improve  the  CASE 
tool's  usability. 

7.  Hard  copy  (printed)  report  options  within  each  toolset 
provide  no  capabilities.  Although  three  font  styles  and 
multiple  font  sizes  exist  for  screen  displays,  the 
printed  reports  use  only  one  font,  which  is  system 
generated  based  on  the  desired  report,  and  not 
controllable  by  the  user.  Graphical  models  can  not  be 
printed  to  a  file;  therefore  large  graphical  models  can 
not  reduce  to  a  viewable  size  with  any  level  of  detail. 
Text-based  models  can  only  be  printed  to  a  file  using 
ASCII  text  or  ASCII  graphics.  Conversion  from  the 
resulting  text  files  to  a  word  processing  software  format 
requires  significant  manual  data  clean-up  and  conversion. 

8.  The  CASE  tool  saves  the  organizational  model  and  all 
model  subsets  in  four  data  files,  which  continue  to  grow 
and  expand  in  size  as  additional  detail  and 
interrelationships  are  defined  within  each  toolset. 
Alternate  data  backup  methods  must  be  used  to  provide  a 
backup  copy  of  the  model  in  case  of  platform  failure. 
Multiple  versions  of  the  same  model  quickly  overwhelm  the 
memory  capacity  of  the  desktop  workstation. 
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D.  FOLLOW-ON  STUDIES  AND  ANALYSES  RECOMMENDATIONS 


This  section  addresses  the  recommendations  for  further 
studies  and  analyses.  Chapter  IV  identifies  numerous 
limitations  to  this  project's  analysis  which  should  be 
resolved  if  this  project  will  serve  as  the  basis  for  follow-on 
study  using  the  information  engineering  methodology.  A 
summary  of  the  projected  requirements  includes: 

1.  Redefine  the  business  activities/functions  in  terms  of 
the  DoD  Enterprise  Activity  Model  functional  areas  and 
functional  activities. 

2.  Once  specific  organizational  goals  are  identified  by  the 
NFS  management  (through  the  Executive  Steering 
Committee) ,  complete  the  analysis  of  the  goals  and 
problems . 

3.  Once  specific  organizational  critical  success  factors 
(CSFs)  are  identified  by  the  NFS  management  (through  the 
Executive  Steering  Committee) ,  complete  the  analysis  of 
the  CSFs. 

4.  Building  on  the  previous  two  analysis  activities,  conduct 
a  strategic  information  systems  study  to  formally 
identify  the  mission-critical  information  systems. 

5.  Obtain  user  feedback  on  the  organizational  activity  and 
data  models  from  all  NFS  organizaitonal  units. 

6.  Obtain  a  complete  listing  of  all  information  systems 
throughout  the  NFS  enterprise,  including  the  interfaces 
with  all  external  systems,  through  terminals  or  modems. 

7.  Frioritize  the  business  area  system  developments. 

8.  Complete  the  full  Business  Area  Analysis  (BAA)  for  each 
business  area,  refining  the  data  model  and  activity  model  • 
to  its  ultimate  detail. 

9.  Based  on  the  results  of  the  full  BAA,  determine 
recommendations  for  organizational  structure  change. 

As  noted,  the  analyses  may  lead  to  reengineering  processes  and 

restructuring  the  NFS  organization  to  support  improved 
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efficiency  and  effectiveness.  The  results  of  these  analyses 
provide  enhancements  to  the  analysis  of  the  NPS  requirements; 
further  analysis  in  this  area  includes  fully  detailing  the 
various  factors  addressed  during  the  initial  analysis. 

In  addition  to  the  follow-on  analyses  of  the  NPS 
enterprise  and  its  needs  or  requirements,  another  recommended 
study  is  the  conduct  of  a  more-detailed  market  survey  to 
identify  specific  vendor  solutions  within  each  data  management 
architecture  alternative.  Once  vendor-specific  implementation 
data  is  available,  the  alternatives  require  another  (or 
further)  analysis  to  identify  the  specific  implementation 
solution. 

E.  FINAL  CONCLUSIONS 

This  thesis  research  project  attempts  to  answer  two 
questions : 

1.  What  is  the  information  architecture  of  the  NPS 
enterprise? 

2.  What  is  the  most  appropriate  data  management  architecture 
for  the  NPS  enterprise  data,  considering  local 
constraints  on  both  financial  and  personnel  resources? 

A  high-level  overview  of  the  NPS  enterprise  information 

architecture  now  exists,  as  described  in  Chapters  IV,  VI,  and 

the  supporting  Appendices.  The  answer  to  the  question  of  an 

approriate  data  management  architecture  is  the  concept  of  a 

client/server  information  processing  architecture,  as 

described  in  Chapters  V,  VI,  and  this  chapter. 
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APPENDIX  A:  AVAILABLE  FEDSIM  DOCUMENTS 


The  Federal  Systems  Integration  and  Management  Center 
(FEDSIM)  and  the  Office  of  Technical  Assistance  (OTA)  in  the 
Information  Resources  Management  Service  (IRMS)  branch  of  the 
U.S.  General  Services  Administration  (GSA)  routinely  publishes 
documents  which  shares  the  information  gained  by  FEDSIM  in  its 
work  with  other  Federal  agencies.  These  publications  are  also 
offered  free  of  charge  to  Government  organizations.  A  listing 
(titles  and  description)  of  some  of  the  documents  available 
from  the  IRMS,  obtained  from  the  FEDSIM  1st  Qtr  FY  1994 
Listing,  is  included  here: 

A.  FEDSIM  Information  Technology  Publications 

Single  copies  of  the  following  documents  are  available 
free  to  Government  organizations: 

The  Site  LlcGnse  Approach  to  Acquiring  Commercial  Off-the- 
Shelf  Softvare.  A  reference  to  assist  agencies  in  the 
acquisition  of  commercial  off-the-shelf  software  using  site 
licensing.  Provides  an  overview  of  factors  to  consider  when 
deciding  whether  to  use  a  site  license  and  key  elements  in  the 
preparation  of  a  site  license  solicitation. 

Hov  to  Buy  Local  Area  Networks.  Provides  guidance  to 
agencies  considering  the  acquisition  of  a  local  area  network 
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(LAN) .  The  document  addresses  cost  benefits;  functional, 
physical,  and  operational  requirements;  design  and 
integration;  procurement;  training;  and  maintenance  issues. 

Performing  a  Requirements  Analysis  for  Acquisition  of 
Federal  Information  Processing  Equipment.  Presents  a 
methodology  for  conducting  a  requirements  analysis  for  FIP 
equipment.  Can  be  used  as  a  reference  for  conducting  a 
requirements  analysis  and  preparing  a  requirements  document 
(RA) ,  and  provides  a  broad  view  of  the  requirements  process. 
Details  the  planning  and  technical  aspects  of  the  process  and 
provides  Federal  managers  with  requisite  procedures. 

A  Methodology  for  Conducting  Federal  Systems  Integration 
Projects.  Describes  a  structured  methodology  that  Government 
agencies  can  use  to  conduct  highly  complex  systems  integration 
projects.  The  document  defines  systems  integration  within  the 
context  of  the  traditional  systems  life  cycle,  outlines  the 
role  of  the  systems  integrator,  and  details  nine  specific  step 
constituting  the  systems  integration  process.  The  document 
also  discusses  tools  and  techniques  that  can  be  employed  to 
support  systems  integration  projects  and  reviews  the  impact 
of,  and  expectations  for,  systems  integration  in  the  1990s. 

A  Guide  to  Alternative  Requirements  Analysis 
Methodologies.  A  reference  to  assist  agencies  with  choosing 
a  information-  and  cost-effective  methodology/technique  for 
performing  requirements  analyses.  Provides  an  overview  of 
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three  requirements-analysis  methodologies  —  Reverse 
Engineering,  the  Delphi  Method,  and  the  Interactive  Design 
methodology. 

Information  Technology  Facility  Management  Review  and 
Evaluation.  An  Information  Technology  Facility  (ITF) 
Management  Review  and  Evaluation  can  lead  to  improved  ITF 
management.  Here  FEDSIM  shares  experience  gained  by  working 
with  agencies  on  projects  related  to  ITF  Management  Review  and 
Evaluation. 

Using  Integrated  Seirvices  Digital  Network  Technology. 

This  document  is  a  guide  for  Federal  government  planners  and 
designers  who  are  considering  the  use  of  Integrated  Services 
Digital  Network  (ISDN)  technology  for  the  first  time  or  who 
are  involved  in  the  actual  selection  and  implementation  of 
ISDN-based  data  communications  networks. 

Improving  Information  Technology  Facility  Management. 
Developed  to  promote  efficient,  effective,  and  economical 
Information  technology  Facility  (ITF)  management,  this 
document  provides  an  overview  within  the  context  of  Federal 
IRM.  It  discusses  four  key  management  controls  —  ITF 
management  reviews  and  evaluations,  capacity  management 
programs,  charging  systems,  and  security  programs.  It 
describes  FEDSIM' s  approaches  to  developing  and  implementing 
these  important  management  controls. 

FEDSIh^osiumf  Volumes  1  and  2.  A  collection  of  articles 
on  a  wide  range  of  information  technology  issues  written  by 
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FEDSIM  personnel  and  published  by  FEDERAL  COMPUTER  WEEK  in  a 
column  called  FEDSIMposium. 

Proceeding’s  of  ’the  Symposium  on  Benchmarking  and 
Alternatives  August  1989.  A  FEDSIM  Symposium,  "Benchmarking 
and  Alternatives,"  was  held  on  August  2,  1989,  to  provide 
current  information  to  agency  and  vendor  personnel  on 
benchmarking  and  alternative  methods  of  performance  validation 
in  acquisitions  of  computer  systems.  This  document  includes 
an  abstract  of  each  presentation  and  reproductions  of  the 
slides  used  during  the  presentations. 

Designing  Data  Communications  Networks .  This  document  was 
prepared  to  help  Federal  managers  and  analysts  design, 
evaluate,  and  select  wide-area  data  communications  networks 
for  certain  classes  of  military  and  agency-unique 
requirements.  It  shares  information  gathered  by  FEDSIM  in  the 
conduct  of  projects  related  to  the  design  of  wide-area  data 
communications  networks  within  the  Government  and  provides 
tools  for  requirements  determination,  performance  prediction, 
and  topology  optimization. 

Information  Technology  Installation  Security.  This 
publication,  addressed  to  Federal  managers  having 
responsibility  for  information  technology  installation  assets, 
provides  an  overview  of  computer  security-related  laws, 
policies,  regulations,  standards,  and  guidelines  and  the 
organizations  responsible  for  their  enactment.  It  defines  the 
components  of  a  security  program  and  provides  procedures  for 
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developing,  implementing,  and  maintaining  a  practical  and 
effective  security  program. 

Model  for  the  Acquisition  of  Software  Support  Services. 

Provides  agencies  with  a  strategy  and  methodology  for 
acquiring  software  support  services.  Includes  a  model  RFP  and 
Proposal  Evaluation  Plan. 

Capacity  Management.  Provides  helpful  information  to 
agencies  on  managing  the  capacity  of  their  systems.  It  is 
based  on  FEDSIM's  experience  with  Federal  implementations. 
The  practical  advice  included  here  will  assist  managers  in 
understanding  and  implementing  a  comprehensive  capacity 
management  program. 

Survey  of  Life  Cycle  Management  Methodologies.  A  survey 
of  23  documents  being  used  throughout  the  Federal  Government 
and  private  industry  pertaining  to  life  cycle  management  of 
information  resources.  Identifies  the  methodologies' 
characteristics  and  documents  conclusions  FEDSIM  derived  from 
the  survey. 

A  Phased  Approach  to  Life  Cycle  Management.  Presents  an 
overview  of  a  life  cycle  management  methodology  developed  by 
FEDSIM  for  information  resources  which  includes  phases  and 
tasks  neglected  or  underemphasized  in  other  methodologies. 
Special  emphasis  is  on  system  acquisition  and  planning. 

Planning  for  and  Acquiring  Data  Communications  Networks . 
Provides  specific  guidance  to  agencies  seeking  to  procure 
major  data  communications  systems.  Provides  a  high-level 
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overview  of  the  five  phases  of  the  acquisition  process, 
focusing  on  the  management,  planning  and  production  of 
required  documents. 

Charging  Systems  for  Information  Technology  Services. 

This  document  provides  guidance  to  Federal  managers  on 
implementing  charging  systems  in  their  information  technology 
facilities.  It  is  a  practical  guide,  based  on  the  experience 
of  FEDSIM  with  Federal  implementations,  and  will  assist 
managers  in:  understanding  the  requirements  of  charging 
systems,  developing  an  implementation  strategy,  sizing  the 
level  of  effort  required,  and  avoiding  pitfalls  experienced  by 
others . 

B.  Other  Information  Technology  Publications 

The  following  documents/products  are  examples  of  other 
items  that  may  be  purchased  from  the  National  Technical 
Information  Service  (NTIS),  U.S.  Department  of  Commerce: 

Programmers  Workbench  Handbook.  Describes  a  practical 
approach  to  planning,  acquiring,  organizing,  coordinating,  and 
implementing  automated  tools. 

Software  Conversion  Lessons  Learned  Volume  1,  By  using  a 
series  of  case  studies,  this  book  provides  the  reader  with  the 
knowledge  and  experience  gained  from  Government  agencies  and 
private  companies  who  converted  major  ADP  systems. 
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Conversion  Cost  Model  (Version  4}  .  IBM  PC  compatible 
software  for  estimating  the  resources  necessary  to  accomplish 
a  software  conversion. 

Conversion  Plan  Outline.  This  book  provides  a  sample 
comprehensive  outline  for  software  conversion  planning. 

Guidelines  for  Planning  and  Implementing  a  Software 
Improvement  Program  (SIP) .  Serves  as  a  starting  point  for 
establishing,  planning,  and  implementing  a  software 
improvement  program  (SIP) .  Emphasizes  the  top-down 
incremental  approach  to  software  improvement  and  explains  what 
you  need  to  do  to  set  up  a  SIP  in  your  organization. 

The  Software  Improvement  Process  —  Its  Phases  and  Tasks 
(Parts  1  and  2) .  This  report  goes  into  great  detail 
discussing  the  phases  and  tasks  needed  for  planning  and 
implementing  a  software  improvement  program  (SIP) . 

A  Software  Tools  Project;  A  Means  of  Capturing  Technology 
and  Improving  Engineering.  An  introduction  to  the  concepts  of 
automated  software  tools  and  what  they  can  contribute  toward 
the  software  engineering  process. 

Software  Improvement  -  A  Needed  Process  in  the  Federal 
Government.  An  easy-to-read  introduction  to  the  concepts  of 
Software  Improvement  and  how  these  concepts  can  be  used  to 
effectively  modernize  Government  software. 
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APPENDIX  B:  FEDERT^  INFORMATION  PROCESSING  STANDARDS 

A.  Federal  Information  Processing  Standards  (FIPS) 

FIPS  are  individual  standards  related  to  automated  data 
processing,  and  are  categorized  in  one  of  five  areas: 
hardware,  software,  application,  data,  and  operations.  Each 
category  also  has  sub-categories,  and  some  FIPS  fall  within 
more  than  one  category,  such  as  FIPS  dealing  with  network 
protocols.  The  first  FIPS  were  issued  in  the  late  1960s  by 
the  U.S.  Department  of  Commerce's  National  Bureau  of 
Standards,  now  known  as  the  National  Institute  of  Standards 
and  Technology  (NIST) .  The  majority  of  the  technical  FIPS 
adopt  American  National  Standards  (ANS)  for  automated  data 
processing  developed  by  the  American  National  Standards 
Institute  s  (ANSI)  X3  Committee  (Computers  and  Information 
Processing) .  Some  adopt  International  Standards  approved  by 
the  International  Standards  Organization  (ISO) ,  or  joint 
ISO/ANSI  standards.  Many  FIPS  are  simply  non-mandatory 
guidelines  written  to  serve  as  technical  references  for  IS 
personnel  in  some  area  of  information  processing.  Some  of 
these  standards  have  been  adopted  and  implemented  commercially 
as  well.  The  Federal  Standards  are  periodically  reviewed,  and 
the  FIPS  are  revised  or  superseded  if  required  whenever  the 
underlying  ISO  or  ANSI  standards  are  updated. 
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The  FIPS  are  too  numerous  to  attempt  to  list  and  describe 
in  their  entirety.  Even  listing  just  the  FIPS  that  can  be 
considered  applicable  to  information  processing  or  information 
management  at  NPS  would  be  excessive;  therefore,  only  a  small 
representative  sampling  of  the  applicable  FIPS  in  each 
category  is  provided  here. 

a .  Hardware  Standards 

CODE  FOR  INFORMATION  INTERCHANGE  (FIPS  PUB  1; 
November  1,  1968)  establishes  a  standard  128  character  code 
set  for  information  interchange  that  corresponds  to  the 
American  National  Standards  Institute's  (ANSI)  American 
National  Standard  (ANS)  X3. 4-1968  [also  known  as  the  American 
Standard  Code  for  Information  Interchange  (ASCII)]. 

CHARACTER  STRUCTURE  AND  CHARACTER  PARITY  SENSE  FOR 
SERIAL-BY-BIT  DATA  COMMUNICATION  IN  THE  CODE  FOR  INFORMATION 
INTERCHANGE  (FIPS  PUB  17;  October  1,  1971)  specifies 
characters  as  seven  ASCII  bits  and  one  character  parity  bit. 
This  standard  adopts  ANSI  ANS  X3. 16-1966,  and  specifies  odd 
parity  for  synchronous  transmissions  and  even  parity  for 
asynchronous  transmissions. 

LOCAL  AREA  NETWORKS:  BASEBAND  CARRIER  SENSE 
MULTIPLE  ACCESS  WITH  COLLISION  DETECTION  ACCESS  METHOD  AND 
PHYSICAL  LAYER  SPECIFICATIONS  AND  LINK  LAYER  PROTOCOL  (FIPS 
PUB  107;  October  31  1984)  is  a  combined  hardware  and  software 
standard.  This  computer  network  protocol  standard  adopts  the 
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Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
standards  802.2  and  802.3,  known  commercially  by  the  term 
Ethernet . 

Jb .  Software  Standards 

VOCABULARY  FOR  INFORMATION  PROCESSING  (FIPS  PUB 
11;  November  15,  1970)  adopts  ANSI  National  Standard 
Vocabulary  for  Information  Processing  X3. 12-1970  and  provides 
an  alphabetical  listing  of  approximately  1,200  entries,  each 
consisting  of  a  term  and  its  definition.  This  FIPS  was 
superseded  by  the  DICTIONARY  FOR  INFORMATION  PROCESSING  (FIPS 
PUB  11-1;  September  30,  1977),  which  adopts  ANSI's  replacement 
standard  X3/TR-1,  American  National  Dictionary  for  Information 
Processing.  FIPS  11-1  was  superseded  in  May  1983  by  an 
updated  version.  FIPS  PUB  11-2  has  since  been  superseded  as 
well.  The  current  FIPS  is  now  GUIDELINE:  AMERICAN  NATIONAL 
DICTIONARY  FOR  INFORMATION  SYSTEMS  (FIPS  PUB  11-3;  February  1, 
1991)  which  adopts  ANSI  Standard  X3. 172-1990  as  a  guideline 
for  use  by  Federal  agencies. 

COMMON  BUSINESS  ORIENTED  LANGUAGE  (COBOL)  (FIPS 
PUB  20;  March  25,1972)  adopts  ANSI's  COBOL  (ANS  X3. 23-1968)  as 
the  Federal  Standard  COBOL. 

GUIDELINE  FOR  PLANNING  AND  USING  A  DATA  DICTIONARY 
SYSTEM  (FIPS  PUB  76;  August  20,  1980)  is  a  basic  reference 
document  which  describes  the  capabilities  of  an  automated  data 
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dictionary  system  and  provides  guidance  for  selection  and  use 
of  such  a  system. 

GUIDELINE  FOR  PLANNING  AND  MANAGEMENT  OF  DATABASE 
APPLICATIONS  (FIPS  PUB  77;  September  1,  1980)  provides  an 
early  version  of  a  basic  reference  which  explains  alternative 
software  capabilities  (then  available)  and  provides 
recommended  development  practices  for  building  database 
applications.  Although  the  FIPS  was  issued  based  on  1970s 
technology,  the  general  principles  for  database  management 
system  development  still  apply. 

GUIDELINE  ON  INTEGRITY  ASSURANCE  AND  CONTROL  IN 
DATABASE  ADMINISTRATION  (FIPS  PUB  88;  August  14,  1981)  serves 
as  a  basic  reference  which  provides  explicit  guidance  to 
achieve  database  integrity  and  security  control.  The  FIPS 
also  provides  a  step-by-step  procedure  for  verifying  a 
database's  accuracy  and  completeness. 

GUIDELINE  FOR  CHOOSING  A  DATA  MANAGEMENT  APPROACH 
(FIPS  PUB  110;  December  11,  1984)  is  a  basic  reference  which 
helps  identify  the  appropriate  data  management  approach  from 
among  three  basic  options:  traditional  application  system 
(file  environment),  database  management  system  (DBMS),  or  a 
data  management  system  (compromise  between  DBMS  and  file 
environment)  . 

ADA  (FIPS  PUB  119;  November  8,  1985)  adopts  ANSI's 
American  National  Standard  Reference  Manual  for  the  Ada™ 
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Programming  Language,  ANSI/MIL-STD-1815A-1983,  as  the  syntax 
and  semantic  rules  standard  format  for  programs  written  in 
Ada™. 

SPECIFICATION  FOR  A  DATA  DESCRIPTIVE  FILE  FOR 
INFORMATION  INTERCHANGE  (DDF)  (FIPS  PUB  123;  September  19, 
1986)  adopts  the  joint  ANSI  and  ISO  Standard  8211-1985,  which 
specifies  media-independent  and  system-independent  file  and 
record  formats  for  the  transmission  of  information  between 
computer  systems. 

GUIDELINE  ON  FUNCTIONAL  SPECIFICATIONS  FOR 
DATABASE  MANAGEMENT  SYSTEMS  (FIPS  PUB  124;  September  30,  1986) 
is  another  basic  reference  document  which  helps  IS  managers 
prepare  a  contract  paperwork  for  development  of  database 
management  systems  based  on  functional  specifications.  The 
guideline  is  divided  into  four  areas:  hardware  and  software 
constraints,  global  data  factors,  data  model  specifications, 
and  other  specifications. 

DATABASE  LANGUAGE  SQL  (FIPS  PUB  127-1;  February  2, 
1990) (supersedes  FIPS  PUB  127  of  March  10,  1987)  adopts  most 
of  the  ANSI  SQL  specifications  in  ANSI  X3. 135-1989  and  ANSI 
X3. 168-1989, and  provides  a  database  language  for  use  in 
database  applications  founded  on  the  relational  data  model. 

COMPUTER  GRAPHICS  METAFILE  (CGM)  (FIPS  PUB  128; 
March  16,  1987)  adopts  ANSI  X3. 122-1986  as  a  graphics  data 
interface  standard  which  specifies  a  device  independent  file 
format  for  use  with  graphical  information. 
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STANDARD  GENERALIZED  MARKUP  LANGUAGE  (SGML)  (FIPS 
PUB  152;  September  26,  1988)  adopts  the  ISO  8879-1986  Standard 
for  specifying  a  language  for  describing  documents  that  are 
processed  by  any  text  processing  system. 

GOVERNMENT  OPEN  SYSTEMS  INTERCONNECTION  PROFILE 
(GOSIP)  (FIPS  PUB  146;  August  24,  1988)  (revised  and 
superseded  by  FIPS  PUB  146-1;  April  3,  1991)  specifies  a  set 
of  ISO's  Open  System  Interconnection  (OSI)  protocols  for 
computer  networking  that  are  intended  for  acquisition  and  use 
by  Federal  agencies.  GOSIP  is  considered  a  combined  hardware 
and  software  standard  since  it  describes  both  types  of 
products  and  services.  The  GOSIP  FIPS  is  considered  a 
mandatory  standard,  since  it  specifies  that  "GOSIP  shall  be 
used  by  Federal  Government  agencies  when  acquiring  computer 
networking  products  and  services  and  communications  systems  or 
services  that  provide  equivalent  functionality  to  the 
protocols  defined  in  the  GOSIP"  (FIPS  PUB  146-1,  1991,  p.l). 
However,  Federal  agencies  are  still  permitted  to  acquire 
network  products  other  than  those  specified  in  GOSIP. 

ELECTRONIC  DATA  INTERCHANGE  (EDI)  (FIPS  PUB  161; 
March  29,  1991)  adopts  the  nationally  and  internationally 
recognized  family  of  standards  known  as  X12  and  EDIFACT. 
These  standards  were  developed  primarily  to  exchange  business 
information,  and  support  the  transmission  of  all  data 
associated  with  a  particular  type  of  functional  document 
together  as  one  electronic  message. 
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c.  Data  Standards 


CALENDAR  DATE  (FIPS  PUB  4;  November  1,  1968)  was 
one  of  the  first  standards  for  formatting  data. 

STANDARDIZATION  OF  DATA  ELEMENTS  AND 
REPRESENTATIONS  (FIPS  PUB  28;  December  5,  1973)  provides 
policy  and  agency  responsibilities  for  a  Federal  Government¬ 
wide  standardization  program.  This  includes  the  definitions 
for  the  different  types  of  data  element  standards,  such  as 
International  Standards,  American  national  Standards,  Federal 
General  Standards,  Federal  Program  Standards,  Agency 
Standards,  Unit  Standards,  and  De  facto  Practices.  The  key 
policy  statement  is  that  "approved  standards  will  be 
implemented  by  all  Federal  agencies  in  all  circumstances  where 
technical,  operating  and  economic  benefits  can  be  expected  to 
result"  (FIPS  PUB  28,  1973,  p.4). 

d.  Operations  Standards 

GUIDELINES  FOR  ADR  PHYSICAL  SECURITY  AND  RISK 
MANAGEMENT  (FIPS  PUB  31;  June,  1974)  provides  guidance  and  can 
be  used  as  an  evaluation  checklist  for  computer  system 
physical  security. 

GUIDELINE  ON  COMPUTER  PERFORMANCE  MANAGEMENT:  AN 
INTRODUCTION  (FIPS  PUB  49;  May  1,  1977)  provides  overall 
guidance  to  automated  data  processing  (ADP)  managers  for 
meeting  end-user  requirements  while  managing  and  planning  for 
ADP  resources. 
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GUIDELINES  FOR  THE  MEASUREMENT  OF  INTERACTIVE 


COMPUTER  SERVICE  RESPONSE  TIME  AND  TURNAROUND  TIME  (FIPS  PUB 
57;  August  1,  1978)  provides  a  methodology  for  measuring 
interaction  times  and  describes  other  functional  performance 
measures . 

GUIDELINES  FOR  ADP  CONTINGENCY  PLANNING  (FIPS  PUB 
87;  March  27,  1981)  provide  broad,  generic  information  to 
assist  information  system  managers  in  the  preparation  of 
contingency  plans. 
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APPENDIX  C:  DESCRIPTION  OF  lEF  “*  TOOLSETS 

This  appendix  provides  an  overview  of  the  graphical 
modeling  tools  available  within  each  toolset  in  the  Texas 
Instruments’  Information  Engineering  Facility™  (lEF™) 
Computer  Aided  Software  Engineering  (CASE)  tool.  The  four 
toolsets  are  the  Planning  Toolset,  the  Analysis  Toolset,  the 
Design  Toolset,  and  the  Construction  Toolset.  The  tools  used 
to  interface  with  the  Central  Encyclopedia  are  also  addressed. 

A.  Planning  Toolset 

A  strategic  top-down  approach  typically  begins  with  the 
Information  Strategy  Planning  stage  using  the  Planning 
Toolset.  During  this  stage,  the  Planning  Toolset  supports  the 
conceptual  model  definition  of  the  information  architecture, 
the  business  system  architecture,  and  the  technical 
architecture . 

1 .  Data  Modeling  -  Subject  Area  Diagrams  (DM) 

Data  modeling  entails  building  a  global  data  model, 
graphically  depicting  a  business's  principal  subject  areas. 
The  subject  areas  can  be  subdivided  into  high  level  entity 
types  in  an  entity-relationship  (ER)  model,  but  this  step  is 
usually  performed  during  the  Business  Area  Analysis  phase. 
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2.  Activity  Hierarchy  -  Function  Hierarchy  Diagram  (AHD) 

The  Function  Hierarchy  Diagram  tool  graphically  models 
business  activities  at  their  highest  level;  these  activities 
are  generally  the  principal  functions  performed  by  the 
business . 

3 .  Activity  Dependency  -  Function  Dependency  Diagrams 

(ADD) 

This  tool  documents  the  functional  sequence  based  on 
the  dependencies  between  functions,  such  as  logic  and  timing 
constraints.  This  diagram  is  also  described  as  a  high-level 
of  abstraction  data  flow  diagram,  with  the  capability  to 
represent  sequential,  parallel,  recursive,  multiple-enabling, 
and  mutually  exclusive  dependencies. 

4.  Organizational  Hierarchy  (OHD) 

The  Organizational  Hierarchy  tool  diagrams  the 
existing  organizational  structure,  and  can  create  multilevel 
organizational  charts. 

5 .  Matrix  Processor  -  Business  Function/Entity  Type 

Matrix  (MTX) 

The  Matrix  Processor  builds  high-level  interaction 
models  between  the  data  model  objects  and  the  functional  model 
objects.  lEF™  provides  over  40  standard  matrices  for 
collecting,  analyzing,  and  clustering  this  information.  A 
matrix  is  automatically  populated  by  IFF™  when  the  data  is 
available  from  the  use  of  the  other  tools;  a  planner  can  also 
directly  enter  the  information  in  the  matrix. 
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6.  Matrix  Definition  (MDF) 

This  tool  functions  like  the  Matrix  Processor,  but 
allows  a  planner  to  create  customized  matrices. 

B.  Analysis  Toolset 

Companies  may  skip  the  Information  Strategy  Planning  phase 
and  simply  take  a  tactical  approach  by  starting  in  the 
Business  Area  Analysis  stage.  During  this  phase  a  specific 
area  of  the  overall  business  is  analyzed  in  detail.  Analysts 
develop  three  components  for  each  business  area:  a  data  model, 
an  activity  model,  and  an  interaction  model.  These  can  simply 
be  subsets  of  the  models  developed  using  the  Planning  Toolset, 
or  built  from  scratch  if  the  Information  Strategy  Planning 
phase  was  omitted.  Therefore,  many  of  the  tools  are  the  same 
as  those  in  the  Planning  Toolset. 

1 .  Data  Modeling  -  Entity  Relationship  Diagram  and  Entity 
Hierarchy  Diagrams  (DM) 

Analysts  use  this  tool  to  develop  the  Subject  Area 
Diagram  for  a  particular  area  of  the  business,  and  create  (or 
refine)  an  ER  diagram.  Entities  are  subdivided  into  entity 
subtypes.  The  underlying  characteristics  of  the  entity  types 
attributes  —  and  the  properties  of  the  relationships  — 
cardinality  and  optionality  —  are  added  to  the  diagrams . 
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2 .  Activity  Hierarchy  -  Process  Hierarchy  Diagram  (AHD) 

Analysts  use  this  tool  to  develop  and  refine  the  high- 
level  functional  hierarchy  diagrams  into  more  detailed  process 
hierarchies,  resulting  in  elementary  processes. 

3 .  Activity  Dependency  -  Process  Dependency  Diagram  (ADD) 

Analysts  use  this  tool  to  expand  the  functional 

dependency  diagrams  by  modeling  the  dependencies  between  lower 
level  processes. 

4.  Action  Diagram  -  Process  Action  Diagram  (PAD) 

lEF™  will  automatically  create  a  Process  Action 
Diagram  (PAD)  for  each  elementary  process  in  the  business 
area.  The  PAD  details  the  steps  within  processes,  summarizing 
how  elementary  processes  view  entities  and  how  they  affect 
entities.  The  statements  created  provide  the  detailed  process 
logic  which  is  the  basis  for  code  generation.  Analysts  can 
also  manually  insert  statements  into  the  PAD,  and  lEF™  will 
prevent  syntax,  semantic,  or  spelling  errors. 

5.  Structure  Chart  (SC) 

The  Structure  Chart  tool  provides  analysts  a  way  to 
see  the  inter-relationships  between  Process  Action  Diagrams  in 
a  hierarchical  manner. 

6.  Action  Block  Usage  (ABU) 

This  tool  simply  provides  the  analyst  with  a  graphical 
view  of  the  hierarchical  list  of  Process  Action  Diagrams. 
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7 .  Matrix  Processor  -  Elementary  Process/Entity  Type 

Matrix  (MTX) 

Analysts  use  the  Matrix  Processor  tool  to  define  the 
effects  of  elementary  processes  on  entity  types,  and  to 
further  define  the  business  systems.  The  techniques  used  are 
the  same  as  those  used  with  the  Matrix  Processor  in  the 
Planning  toolset. 

8 .  Matrix  Definition  (MDF) 

As  in  the  Planning  toolset,  this  tool  provides  a 
capability  to  create  customized  matrices. 

9.  Business  System  Definition  (DBS) 

This  tool  provides  a  method  for  defining  business 
systems  in  preparation  for  the  next  phase.  The  objective  of 
using  this  tool  is  to  group  elementary  processes  into  business 
systems,  ranked  by  priority. 

C.  Design  Toolset 

lEF™  supports  two  stages  of  the  information  engineering 
methodology  with  the  Design  Toolset:  Business  System  Design 
and  Technical  Design.  System  designers  use  this  toolset  to 
determine  implementation  details,  such  as  procedure  flows, 
user  screen  formats,  and  data  base  management  systems.  The 
Design  Toolset  provides  a  number  of  automatic  transformations 
of  the  business  model  which  conceptually  represent  the 
physical  implementation  of  the  business  systems. 
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1.  Dialog  Flow  -  Dialog  Flow  Diagram  (DLG) 

Designers  use  this  tool  to  detail  control  and  data 
flows  between  procedures  and  sequencing  between  user  screens 
or  other  graphical  user  interfaces  for  on-line  interactive 
systems,  or  sequence  and  flow  of  batch  job  steps  for  batch 
applications . 

2.  Screen  Design  (SD) 

This  tool  provides  designers  a  means  to  build  screens 
for  on-line  applications.  Recurring  screen  elements  are  the 
basis  for  building  reusable  templates  and  global  system 
defaults . 

3 .  Prototyping  (PT) 

Designers  can  use  this  tool  to  demonstrate  the  screen 
views  to  potential  end-users,  who  can  preview  the  presentation 
and  the  flow  between  screens  before  the  supporting  logic  is 
installed. 

4.  Action  Diagram  -  Procedure  Action  Diagram  (PAD) 

This  tool  is  similar  to  the  Action  Diagram  tool  in  the 
Analysis  Toolset,  and  is  used  to  refine  the  detailed  logic  of 
procedures . 

5.  Structure  Chart  (SC) 

This  tool  performs  the  same  functions  in  this  toolset 
as  in  the  Analysis  Toolset. 
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6.  Action  Block  Usage  (SBU) 

This  tool  performs  the  same  functions  in  this  toolset 
as  in  the  Analysis  Toolset. 

7.  Data  Structure  -  Data  Structure  Diagram  (DSD) 

This  tool  provides  designers  with  a  graphical 
representation  of  the  physical  data  base  layout  in  order  to 
optimize  the  results  of  IEF™'s  automatic  transformation  of 
earlier  data  diagrams. 

D.  Construction  Toolset 

lEF™  develops  100%  of  the  source  code  in  the  target 
programming  language  for  the  target  hardware 
(moni tor/terminal )  and  the  target  data  base  management  system. 
This  toolset  provides  the  designer  the  controls  for  this 
feature.  The  toolset  also  provides  a  means  to  test  the  full 
application  after  coding. 

1.  Interactive  Diagram  Testing 

This  tool  provides  the  designer  with  the  capability  to 
perform  high-level  debugging  at  the  action  diagram  level. 

E.  Central  Encyclopedia  Toolset 

A  set  of  integrated  host  tools  provides  coordinated  access 
to  the  Central  Encyclopedia,  and  allows  centralized  reporting 
and  model  distribution  management. 
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1 .  Model  Subsetting 

This  tool  provides  a  means  for  multiple  developers  to 
share  the  same  model  without  contention  while  still 
maintaining  model  integrity,  by  allowing  model  subset 
distribution. 

2 .  Model  Merge 

This  tool  provides  the  mechanism  to  combine  multiple 
model  subsets  into  a  single  composite  model. 

3 .  Version  Control 

This  tool  permits  developers  to  maintain  multiple 
copies  of  the  same  model  at  different  stages  of  development, 
testing,  and  production. 


I 
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APPENDIX  D:  NPS  ANALYSIS  lEF  ™  PRINTOUTS 

This  appendix  provides  the  lEF™  system  printouts  in 
support  of  the  Chapter  IV  analysis  of  the  NPS  enterprise.® 
The  contents  of  each  Tab  is  identified  below: 


TAB 

A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N 


DESCRIPTION 

Organizational  Hierarchy  Diagram  (AHD) 
Top-Level  Functions  in  Activity  Hierarchy 
Function  vs.  Organizational  Unit  Matrix 
Subject  Areas,  Entity  Types,  Relationships 
Entity-Relationship  Diagram  (Foldout) 

Function  vs.  Entity  Type  Matrix 

Entity  Type  vs.  Organizational  Unit  Matrix 

Function  vs.  Entity  Type  Matrix  (Clustered) 

Info  System  vs.  Organizational  Unit  Matrix 

Info  System  vs.  Entity  Type  Matrix 

Info  System  vs.  Function  Matrix 

Entity  Type  and  Entity  Sub-type  Attributes 

Activity  Hierarchy  Diagram  (AHD)  Decomposition 

Activity  Definition  Report 


®  This  appendix  has  a  separate,  limited  distribution  due 
to  its  size.  Copies  of  this  appendix  may  be  requested  from 
the  Naval  Postgraduate  School,  Monterey,  California,  93943- 
5000. 
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APPENDIX  E:  MIDDLEWARE  TECHNOLOGY 


This  appendix  provides  a  discussion  of  middleware, 
including  a  definition,  a  description  of  use,  and  selected 
examples  of  database  middleware  technologies  and  products. 

A.  MIDDLEWARE 

The  term  middleware  has  many  differing  connotations. 
Middleware  (or  midware)  can  refer  to  architectures,  languages, 
communications  programs,  or  simply  application  programming 
interfaces  (API)^°.  IS  specialists  primarily  use  the  term  when 
discussing  client/server  or  distributed  processing 
environments;  most  agree  that  middleware  in  this  context  is 
any  software  that  provides  a  common  method  for  accessing  data 
from  different  types  of  Data  Base  Management  Systems  (DBMS) 
across  a  network  (Oski,  1993;  Byron,  1994;  Paul  and 
Richardson,  1994)  .  Figure  E.l  provides  a  graphical  definition 
of  middleware. 

Some  middleware  products  provide  only  limited  or  specific 
features;  other  products  are  more  flexible  and  provide  a  full 
range  of  functions  and  services.  Greater  flexibility  has  a 
downside,  which  is  loss  in  system  performance.  For  example. 


An  Applications  Programming  Interface  (API)  is  a  set 
of  function  and  call  programs  that  allows  a  client  application 
to  intercommunicate  with  one  or  more  server  applications. 
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the  rigorous,  real-time  performance  requirements  of  on-line 
transaction-processing  (OLTP)  systems  often  require  database- 
specific  middleware,  which  allows  multiple  different  clients 
to  access  a  specific  DBMS;  database-neutral  middleware,  which 
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allows  a  client  to  connect  to  a  variety  of  DBMSs,  can 

generally  meet  the  performance  requirements  of  a  decision 

support  system.  One  analyst  asks: 

Should  the  database  engine  you  choose  dictate  the  method 
you  use  to  access  data,  or  should  the  clients'  need  to 
access  data  from  a  variety  of  databases  take  precedence? 
(Oski,  1994) 

Middleware  generally  consists  of  three  components:  an  API 
for  one  or  more  applications,  one  or  more  communications 
protocols,  and  one  or  more  drivers.  Three  core  technology 
categories  of  middleware  exist:  Remote  Procedure  Calls  (RPC), 
Message  Queuing  Software  (also  known  as  Message  Oriented 
Middleware,  or  MOM),  and  Object  Request  Brokers  (ORB).  (Paul 
and  Richardson,  1994) 

Remote  Procedure  Call  (RPC)  systems  are  integrated  with 
naming  and  security  services  so  that  clients  and  servers  can 
locate  and  identify  each  other,  even  in  large  distributed 
networks.  RPCs  use  synchronous  communications  to  execute  a 
set  of  instructions  on  a  remote  machine,  through  what  appears 
to  be  a  local  procedure  call,  and  wait  for  a  response. 
Because  synchronous  communications  are  used  (i.e.,  the  client 
sends  a  request  and  must  wait  for  the  response) ,  fast  network 
performance  is  critical  to  obtaining  satisfactory  response 
times  when  using  RPC  middleware-  (Paul  and  Richardson,  1994; 
Spector  and  Eppinger,  1994) 

The  Open  Software  Foundation  (OSF),a  vendor  consortium  of 
major  companies  including  IBM,  Digital  Equipment  Corporation 
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(DEC) ,  and  Hewlett-Packard  Company  (HP) ,  bases  its  proposed 
standard  Distributed  Computing  Environment  (DCE)  on  an 
underlying  RPC  transport  framework.  DCE  is  a  framework  built 
on  an  RPC  transport  mechanism  which  attempts  to  integrate 
numerous  functions  in  a  distributed  processing  environment. 
Currently  defined  features  include  Remote  Procedure  Calls 
(RPC) ,  Threads,  Directory  Service,  Distributed  File  System, 
Security  Service,  and  Distributed  Time  Service  components. 
RPCs,  defined  earlier,  are  the  cornerstone  of  the  DCE. 
Threads  enable  multiple  client  calls  to  be  made  to  a  process 
without  loading  the  process  multiple  times,  resulting  in 
better  performance  and  memory  use.  The  Directory  Service  is 
a  store  of  the  names  of  global  and  local  resources.  The 
Distributed  File  System  provides  users  with  a  common  file 
system  across  different  operating  systems.  The  Security 
Service  maintains  a  security  database  for  each  cell  (local 
grouping  of  users  and  systems)  which  provides  authentication 
and  security  access  rights  based  on  the  Massachusetts 
Institute  of  Technology's  (MIT)  Kerberos  security  program. 
The  Distributed  Time  Service  synchronizes  all  the  host  clocks 
on  the  system.  Additional  planned  features  provide  greater 
functionality  and  additional  services.  Figure  E.2  provides 
a  graphical  depiction  of  the  DCE  architecture.  (Gallagher, 
1994;  Bozman,  1994) 

Message  Queuing  Service  middleware  products  use  high-level 
APIs  and  asynchronous  communications  to  pass  information. 
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Figure  E.2  Distributed  Computing  Environment  Architecture 
(Bozman,  1994) 


These  products  use  queues  to  transfer  data:  client  queues 
hold  the  initial  requests,  which  transfer  across  the  network 
whenever  an  opportunity  window  opens;  and  server  queues  hold 
the  arriving  requests;  the  response  returns  through  the  queues 
in  reverse  order.  Queues  log  or  hold  messages,  support 
delivery  acknowledgement,  priority  handling,  and  content 
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translation  between  platforms.  Since  asynchronous 

communications  are  used,  the  client  can  continue  processing 
while  waiting  for  the  response  to  a  request;  this  provides  the 
message  queuing  method  with  a  significant  advantage  over  the 
REC  method.  Since  queues  are  used,  no  constraints  on  the 
application  structure  exist,  i.e.,  a  queue  can  send  a  message 
to  one,  many,  or  all  queues,  and  vice  versa.  (Yeamans,  1994; 
Paul  and  Richardson,  1994) 

Object  Request  Brokers  (ORB),  a  product  of  object-oriented 
programming  and  development,  manage  the  exchange  of  messages 
between  objects  across  a  network.  ORBs  generally  use  RPCs  as 
an  underlying  transport  mechanism  for  managing  interactions, 
and  support  high-level  APIs.  The  Object  Management  Group 
(OMG) ,  a  vendor  consortium,  defines  standards  for  ORBs  in  the 
Common  Object  Request  Broker  Architecture  (CORBA) .  In  CORBA, 
clients  send  requests  to  an  ORB,  which  locates  the  server, 
forwards  the  request,  receives  the  reply,  and  returns  the 
reply  to  the  client.  Using  a  standard  Interface  Definition 
Language  (IDL),  a  client  can  access  any  server  independent  of 
server  location,  operating  system,  platform,  or  server 
programming  language.  (Siegel,  1994;  Paul  and  Richardson, 
1994) 

These  three  technologies  provide  the  underlying  support 
for  many  different  categories  of  middleware,  including: 

1.  Network  middleware 

2.  Database  middleware 
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3.  Conversion  middleware 


4.  Graphical  User  Interface  (GUI)  middleware 

5.  Software  development  middleware 

Network  middleware  allows  application  developers  to  build 
applications  which  can  communicate  at  any  network  layer;  this 
category  can  use  any  of  the  three  middleware  technologies. 
Database  middleware  provides  mechanisms  for  accessing  and 
manipulating  data  in  a  remote  database.  Database  middleware 
consists  primarily  of  Structured  Query  Language  (SQL) 
interfaces  between  databases.  Some  people  even  claim  that 
relational  DBMSs  (RDBMSs)  and  object-oriented  DBMSs  (OODBMSs) 
can  be  considered  database  middleware.  Conversion  middleware 
includes  products  which  perform  transparent  conversion  of 
text,  graphics,  and  other  data  elements  used  in  applications. 
Conversion  middleware  is  bundled  with  some  database  middleware 
for  interfacing  some  DBMSs  that  allow  multiple  data  types. 
GUI  middleware  provides  an  application  using  different  GUIs 
access  to  a  single  application  data  source.  An  example  of  a 
GUI  middleware  is  terminal  emulation  software  for  a  specific 
application.  Software  development  middleware  consists  of 
CASE-like  tools  and  other  fourth-generation  programming 
language  (4GL)  tools  that  can  shorten  development  time. 

Database  middleware  products  encompass  the  primary  form  of 
middleware  that  would  be  used  in  a  client/server  or 
distributed  data  processing  information  architecture. 
Numerous  vendors  provide  database  middleware  products  today; 
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they  are  too  numerous  to  list  and  describe  here.  A  brief 
description  of  selected  examples  provides  an  overview  of  the 
database  middleware  field.  Examples  of  products  based  on  SQL 
include  Microsoft  Corporation's  Open  Data  Base  Connectivity 
(ODBC) ;  the  IBM,  Novell,  WordPerfect  Corporation,  and  Borland 
International  Inc.  consortiiim' s  Independent  Database 
Application  Programming  Interface  (IDAPI);  and  Apple  Computer 
Inc.'s  Data  Access  Language  (DAL).  Other  types  of  approaches 
include  gateways,  such  as  Information  Builders  Inc.'s 
Enterprise  Data  Access/SQL  (EDA/SQL);  protocols,  such  as  IBM's 
Distributed  Relational  Database  Architecture  (DRDA)  and  ISO's 
Remote  Database  Access  standard  (RDA) ;  and  frameworks  such  as 
Object  Systems'  Distributed  Object  Integration  Tool  (DOIT). 
Some  middleware,  such  as  Forrester  Research  Inc.'s  "data 
switches",  is  purely  theoretical.  The  following  sections 
further  describe  these  example  approaches. 

1.  Structured  Query  Language  (SQL) 

Since  many  database  middleware  products  are  based  on 
the  Structured  Query  Language  (SQL) ,  at  least  a  brief 
discussion  of  SQL  is  in  order.  SQL,  originally  developed  by 
IBM  in  the  1970s  under  the  name  SEQUEL,  is  currently  the  de 
facto  as  well  as  the  de  jure  accepted  standard  data  access 
language  for  use  with  relational  and  distributed  databases. 
Many  variants,  or  dialects,  of  SQL  exist  due  to  vendor- 
specific  extensions  of  the  basic  standard;  the  differences  in 
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functionality  can  be  significant,  and  render  two  SQL  dialects 
incompatible.  The  American  National  Standards  Institute 
(ANSI)  and  the  International  Standards  Organization  (ISO) 
jointly  endorse  a  specific  version  of  SQL  as  a  standard,  known 
as  ANSI/ISO  SQL;  the  standard  is  reviewed  and  updated  on  a 
periodic  basis.  The  other  most  common  version  is  known  as  IBM 
or  DB2  SQL,  or  ANSI  SQL  with  DB2  extensions.  ANSI  SQL  is  also 
a  designated  Federal  Information  Processing  Standard  (FIPS  127 
series) . 

SQL  is  not  a  full-application  development  language;  it 
is  a  data  access  language.  SQL  has  three  components  for 
manipulating  data  and  performing  queries  in  relational 
databases : 

1.  A  data  definition  language  for  creating  relational 
tables,  creating  indexes  to  data,  and  defining  fields  of 
data. 

2.  A  data  manipulation  language  for  entering  information 
into  a  database  and  accessing  and  formatting  the  data. 

3.  A  data  control  language  for  handling  security  functions. 
(Sprague  and  McNurlin,  1993,  p.  216) 

SQL  is  also  a  non-procedural  transform-oriented  language, 

meaning  an  input  consisting  of  one  or  more  relations  (tables) 

is  manipulated  (transformed)  into  a  single  relation  output. 

A  new  SQL-based  API,  Call  Level  Interface  (CLI) ,  is 
the  current  project  of  a  vendor  consortium  known  as  the  SQL 
Access  Group  (SAG)  .  SAG's  CLI  standardizes  on  a  common  set  of 
programming  subroutines  to  provide  interoperability  through  a 
standard  interface.  A  crucial  element  of  the  CLI  API  is  the 
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client  library,  which  contains  the  vendor-specific  server's 
networking  component  and  the  vendor's  SQL  implementation. 
The  CLI  API  definition  includes  the  SAG's  version  of  SQL, 
which  is  based  on  the  1992  ANSI/ISO  SQL  standard.  SAG's  CLI 
SQL  includes  several  extensions,  such  as  management  of 
indexes,  that  are  not  currently  in  the  ANSI  SQL  standard; 
however,  CLI  SQL  is  for  the  most  part  a  subset  of  the  ANSI  SQL 
standard.  The  CLI  definition  is  under  review  by  numerous 
standards  bodies,  including  the  X/Open  vendor  group,  ANSI,  and 
ISO,  and  industry  analysts  expect  CLI  to  be  incorporated  into 
the  ANSI  SQL  standard  in  the  future.”  (Holt,  1994;  Sprague 
and  McNurlin,  1993,  p.  216) 

2.  Open  Data  Base  Connectivity  (ODBC) 

Microsoft  Corporation's  Open  Data  Base  Connectivity 
(ODBC)  is  an  industry-standard  database  protocol  based  on  the 
snapshot  (first  of  three)  stage  of  the  SAG's  CLI  API.  ODBC 
allows  client  applications  to  access  data  from  relational  or 
flat  file  databases.  But  just  as  the  SAG's  CLI  requires 
additional  components  for  full  implementation,  ODBC  also 
requires  additional  vendor-specific  components,  depending  on 
the  nature  of  the  client,  the  network  interface,  and  the 
database  engine.  The  ODBC  core  components  include: 


”  Developers  can  obtain  copies  of  the  SQL  Access  Group's 
Call^  Level  Interface  (CLI)  specification,  which  has  been 
published  as  an  X/Open  Snapshot,  Call  Level  Interface  (CLI), 
for  $70.00  by  calling  603-434-0802. 
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1.  A  library  of  Remote  Procedure  Calls  (REC)  for  connection 
to  the  server,  execution  of  a  request,  and  retrieval  of 
data  into  the  client. 

2 .  A  standard  SQL  syntax,  based  on  the  snapshot  version  of 
the  SAG’S  CLI  API. 

3.  A  standardized  set  of  error  codes. 

4.  Standard  mechanisms  for  connecting  and  logging  on  to 
servers . 

5.  A  standard  representation  of  data  types. 

The  architecture  of  a  system  using  ODBC  would  include: 

1.  An  application  at  the  client  which  can  make  ODBC  calls  to 
the  ODBC  Driver  Manager. 

2.  A  Driver  Manager  which  loads  data  source  drivers  on 
behalf  of  the  clients.  (Under  Microsoft's  Windows,  this 
is  generally  implemented  as  a  Dynamic  Link  Library  (DLL) 
component.)  This  is  the  heart  of  the  ODBC  scheme. 

3.  Drivers  (vendor-specific)  which  process  ODBC  calls  passed 
from  the  client,  submit  SQL  requests  to  a  specific  data 
source,  and  perform  any  necessary  SQL  syntax  translation 
to  or  from  the  ODBC  standard  syntax.  (Under  Windows, 
these  are  usually  included  in  the  DLL;  under  Macintosh 
System  7,  drivers  are  implemented  as  Shared  Library 
Management  System  objects.) 

4.  A  data  source  (the  server  —  includes  the  DBMS,  the 
underlying  operating  system,  and  the  network  interfaces)  . 
(Davies,  1993;  Shaw,  1994) 

ODBC  drivers  perform  functions  analogous  to  network 
printer  drivers.  ODBC  defines  two  types  of  drivers,  single¬ 
tier  and  multiple-tier .  A  single-tier  driver  processes  both 
ODBC  calls  and  SQL  statements,  while  a  multiple-tier  driver 
only  processes  ODBC  calls,  and  passes  SQL  statements  to  the 
DBMS  query  engine.  In  general,  flat-file  databases  use 
single-tier  drivers,  and  relational  databases  use  multiple- 
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tier  drivers.  In  order  to  avoid  the  weaknesses  of  a  least- 
coinmon-denorainator  approach  typical  of  generic  coininon- 
interface  approaches,  ODBC  matches  the  varying  power  of  any 
particular  DBMS  to  the  requirements  of  the  application  through 
the  concept  of  driver  capabilities  and  conformance  levels. 

All  ODBC  drivers  must  implement  a  minimum  specified 
capability  or  functionality  level,  known  as  the  Core  functions 
level.  The  Core  functions  are  23  functions  based  on  the  SAG's 
CLI  specification.  The  Core  functions  provide  the  following 
capabilities:  connect  and  disconnect  from  the  database, 
prepare  and  execute  SQL  statements,  map  parameters  and  result 
sets  to  and  from  the  client  database,  commit  and  rollback 
transactions,  and  receive  error  information.  Two  additional 
categories.  Level  One  and  Level  Two,  provide  extended 
functionality.  Each  category  is  a  superset  of  the  preceding 
category.  Most  commercially  available  ODBC  drivers  today 
only  provide  Level  One  functionality.  Level  One  functionality 
provides  these  additional  capabilities  in  15  functions: 
connect  to  the  DBMS  using  DBMS-specific  dialog  boxes,  get 
basic  systems  catalog  information  (metadata) ,  get  driver 
capabilities  (metadata) ,  send  and  retrieve  long  parameter  and 
result  values  (includes  Binary  Large  Objects,  or  BLOBs),  and 
get  and  set  statement  and  connection  options.  Full  Level  Two 
functionality  provides  54  functions.  Level  Two  functionality 
includes  these  additional  capabilities  in  16  functions:  browse 
available  connections  and  data  sources,  send  and  retrieve 
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arrays  of  parameter  and  result  values,  retrieve  parameter 
count  and  describe  parameters,  use  scrollable  cursers  to 
browse  and  update,  get  enhanced  catalog  information,  and 
international  character  support.  (Intergraph,  1994; 
Satterfield,  1993;  Maloney  and  Archer,  1994) 

ODBC  drivers  also  differ  in  the  level  of  SQL  they 
support;  ODBC  defines  three  levels  of  SQL  conformance: 
Minimum,  Core,  and  Extended.  The  Core  level  is  equivalent  to 
the  SQL  Access  Group's  CLI  specification  syntax.  The  Minimum 
level  is  a  subset  of  the  Core  level  which  is  primarily 
designed  for  use  with  single-tier  drivers.  The  Extended  level 
provides  features  that  go  beyond  the  CLI  specification. 
Higher  levels  provide  more  fully  implemented  Data  Definition 
and  Data  Manipulation  Language  (DFL  and  DML)  support. 
(Intergraph,  1994;  Satterfield,  1993) 

ODBC  also  provides  three  levels  of  data  type 
conformance,  categorized  with  the  same  levels  as  SQL 
conformance.  ODBC  drivers  do  not  need  to  match  the  data  type 
conformance  level  to  the  SQL  syntax  conformance  level,  and 
typically  do  not,  as  third-party  vendors  frequently  provide 
more  extensive  data  type  support  with  reduced  SQL  grammar 
implementations.  (Satterfield,  1993) 


An  Intergraph  White  Paper,  Intergraph  ODBC  Drivers, 
dated  May  5,  1994,  provides  an  excellent  description  of  the 
functions  in  each  ODBC  function  category,  as  well  as 
descriptions  of  the  different  SQL  and  data  type  conformance 
levels . 
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An  ODBC  application  adapts  itself  to  the  capabilities 
of  whichever  DBMS  it  happens  to  be  connected  to  at  the  moment. 
Therefore,  the  ODBC  designers  take  the  approach  that  the 
front-end  (application)  developer  (and  not  the  driver 
developer)  should  make  design  and  implementation  decisions 
regarding  application  behavior  when  certain  DBMSs  features  are 
unavailable  due  to  different  conformance  levels. 

3 .  Independent  Database  Application  Programming  Interface 
(IDAPI) 

The  Independent  Database  Application  Programming 
Interface  (IDAPI)  is  a  data  access  API  promoted  by  the  vendor 
consortium  of  IBM,  Novell,  WordPerfect,  and  Borland.  IDAPI  is 
also  based  on  the  SQL  Access  Group's  CLI  specification,  but 
goes  far  beyond  the  CLI  specification's  functionality  by 
adding  81  additional  functions,  including  a  number  of  DBMS- 
specific  calls  for  Borland's  navigational  DBMSs.  The  key 
functionality  provided  by  IDAPI  is  the  ability  to 
transparently  access  not  only  relational  and  flat-file 
databases  (like  ODBC)  but  also  navigational  databases^^,  such 
as  those  developed  by  Borland  for  use  on  PCs  (dBASE,  Paradox)  . 
The  method  used  by  IDAPI  consists  of  a  two-part  API  with  a 
supporting  runtime  environment.  One  part  of  the  API  deals 


A  navigational  database  uses  a  model  where  data  is 
stored  as  a  series  of  records.  Individual  data  elements  are 
accessed  by  "navigating"  through  a  collection  of  records  until 
the  desired  data  is  found.  This  is  the  model  used  by  DBMSs 
implemented  on  PCs,  such  as  Btrieve,  dBASE,  Paradox,  and 
others.  (Q+E,  1994,  p.8) 
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with  relational  and  flat-file  databases  using  SQL-type 
commands;  the  other  part  of  the  API  deals  with  navigational 
databases  using  specific  navigational  commands.  Many  of  the 
issues  surrounding  IDAPI  technology  and  implementation  remain 
a  mystery  because  IDAPI  is  not  yet  available  for  use  by 
developers.  However,  some  aspects  of  the  IDAPI  framework  are 
available. (Kernighan,  1993;  Rymer,  1993) 

The  IDAPI  architecture  is  relatively  straightforward. 
In  the  simplest  form,  a  client  application  makes  an  IDAPI 
function  call  to  the  IDAPI  Object  Layer,  which  passes  the  call 
to  the  IDAPI  SQL  Driver.  If  necessary,  the  IDAPI  SQL  Driver 
translates  the  call  to  a  native  call  the  target  DBMS 
understands.  The  "IDAPI  Technology"  consists  of  an  Object 
Layer,  a  Service  Layer,  and  the  SQL  Driver. 

The  Object  Layer  is  the  core  of  the  IDAPI  technology, 
and  is  designed  to  manage  the  IDAPI  environment,  including 
information  about  available  databases  and  database  drivers. 
This  layer  receives  calls  from  the  client  application  and 
handles  them,  making  its  own  calls  to  drivers,  local  database 
engines,  and  the  IDAPI  service  modules.  The  Object  Layer  also 
manages  client  application  sessions,  by  allocating  resources 
and  initiating,  terminating,  and  switching  sessions.  Finally, 
the  Object  Layer  provides  error-handling  support. 

Developers  interested  in  more  information  about  IDAPI 
can  request  the  draft  IDAPI  specification  by  fax  (408-439- 
9343) .  Requests  for  information  can  also  be  phoned  to  800- 
344-4394  or  408-431-5209. 
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Complementing  the  Object  Layer  is  the  Service  Layer, 
which  consists  of  a  number  of  service  modules,  including  an 
Operating  System  Module,  a  Language  Module,  and  a  buffer 
management  service.  These  modules  provide  implementation 
portability;  one  can  simply  replace  one  module  with  another 
corresponding  module  when  porting  IDAPI  to  another  system. 
The  Operating  System  Module  provides  the  operating  system- 
specific  functions,  such  as  file  input/output  (I/O)  and  memory 
management.  The  Language  Module  provides  multiple  character 
sets  for  support  of  different  languages.  The  buffer 
management  service  module  simply  centralizes  buffer  management 
throughout  the  environment.  Additional  support  includes  in¬ 
memory  table  management,  cache  BLOB  data  management,  and  data 
record  sorting.  The  SQL  Driver  provides  the  translation 
between  navigational  calls  and  SQL  calls  through  emulation  of 
navigational  functions.  (Kernighan,  1993) 

IDAPI  has  a  total  of  106  functions,  which  are  broken 
down  into  ten  functional  categories: 

1.  Environment  and  Connection  (17) 

2.  Resources  and  Capabilities  (3) 

3.  Catalog  and  Schema  (3) 

4.  Statement  Preparation  and  Execution  (17  -  14  of  which  are 
SAG  CLI  specification  functions) 

5.  Data  Definition  (11) 

6.  Data  Manipulation  (30) 

7.  Transaction  Management  (2) 
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8.  Error  (1) 

9.  DBMS  or  0/S  Specific  (21) 

10.  Composite  (1) 

Some  of  these  functions  are  defined  as  specific  to  particular 
non-relational  DBMSs,  and  therefore  provide  little  or  no 
functionality  to  SQL  database  users.  (Kernighan,  1993) 

IDAPI  has  three  design  configurations:  IDAPI  as  a  client, 
IDAPI  as  a  server,  and  IDAPI  as  an  integration  server.  As  a 
client,  IDAPI  generates  native  DBMS  calls  through  its  drivers 
to  be  passed  over  the  network  to  the  database  servers.  As  a 
server,  IDAPI  processes  IDAPI  calls  and  handles  the 
communication  of  results  and  errors  using  all  the  network's 
protocols.  As  an  integration  server,  IDAPI  acts  like  a  hub, 
integrating  the  communications  with  multiple  DBMS  servers. 
(Kernighan,  1993) 

IDAPI  middleware  provides  other  important  programmer 
and  user  services.  One  of  the  most  useful  of  these  expected 
services  is  the  ability  to  perform  cross-database  operations, 
such  as  heterogeneous  joins.  IDAPI  also  allows  simultaneous 
connection  to  multiple  DBMSs,  supports  the  placement  of 
multiple  "bookmarks"  on  each  cursor,  and  supports  scrollable 
cursers . 

IDAPI  designers  claim  IDAPI  will  support  ODBC  by 
providing  an  IDAPI  driver  that  treats  ODBC  as  another  native 
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database;  however,  the  proposed  version  of  IDAPI  does  not 
support  all  the  ODBC  function  calls,  so  incompatibility 
remains  an  issue. 

4 .  Other  Data  Access  Methodologies 

Other  methodologies  for  accessing  data  from 
heterogeneous  databases  across  a  network  exist,  but  are  not  as 
widespread  or  supported  throughout  industry  as  ODBC  (or  even 
the  non-existent  IDAPI) . 

a.  Data  Access  Language  (DAL) 

Apple  Computer  Inc.'s  DAL^^  is  an  ANSI  SQL-based 
database  access  product  that  connects  Macintosh  and  Windows 
(through  ODBC)  client  applications  with  12  different  databases 
across  a  wide  variety  of  server  platforms.  DAL  uses  a  single 
API  --  Microsoft's  ODBC.  In  addition  to  full  support  for 
ODBC,  accessible  through  Macintosh's  Data  Access  Manager  APIs, 
DAL  provides  15  function  calls  for  non-ODBC  implementations. 
The  DAL  SQL  dialect  includes  extensions  for  procedure  support 
and  data  type  mapping,  and  is  translated  to/from  target  DBMSs 
SQL  dialects  by  the  DAL  Server  component.  (Independence 
Technologies,  Inc.,  1994) 

jb.  Enterprise  Data  Access/SQL  (EDA/SQL) 

Information  Builders  Inc.'s  Enterprise  Data 
Access/SQL  (EDA/SQL)  is  a  very  powerful  middleware  product 


Independence  Technologies,  Inc.  actually  provides  and 
licenses  the  Data  Access  Language  technology. 
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which  provides  front  ends  with  access  to  relational, 
hierarchical,  flat-file,  and  navigational  databases  through  a 
single  SQL  API  implementation.  EDA/SQL  currently  provides 
support  for  over  50  different  DBMSs  and  file  structures 
residing  on  over  35  hardware  platforms  and  operating 
environments.  Figure  E.3  shows  EDA/SQL's  interfaces. 

EDA/SQL  uses  a  multi-layered  architecture  that 
includes  database-specific  drivers,  a  universal  SQL 
translator,  network  navigation  and  connectivity,  and  an 
API/SQL  interface.  Using  RPC  as  an  underlying  transport 
mechanism,  EDA/SQL  is  conceptually  a  gateway  or  hub  server, 
with  four  functions:  Locate,  Secure,  Warehouse,  and  Manage. 
The  Locate  function  refers  to  the  use  and  maintenance  of  a 
directory  or  catalog  which  helps  provide  request  routing  and 
distribution  with  location  transparency.  The  Secure  function 
refers  to  the  ability  to  provide  a  single  security 
authentication  point  at  the  EDA/SQL  hub,  down  to  the  database 
field  level.  The  Warehouse  function  supports  data  quality 
management  as  the  data  is  transformed  by  installed  business 
rules.  The  Manage  function  provides  data  and  systems 
management  and  management  related  tools,  including  a  query 
governor/statistics  collector,  data  replication  and  copy 
management,  and  integrated  GUI  system  administration  and 
management.  EDA/SQL  gateways  also  exist  for  some  specific 
DBMSs,  including  a  high  performance  relational  gateway  for 
IBM's  DB2  DBMS.  EDA/SQL  supports  and  provides  standards 
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Figure  E.3  IBI's  Enterprise  Data  Access/SQL  (EDA/SQL) 
(IBI,  1993,  p.  2) 


compliance  with  other  industry  activities,  including  the  SAG’s 
CLI,  ODBC,  DRDA,  and  DCE.  (IBI,  1994;  IBI,  1993,  p.  2) 
Industry  analysts  believe  that  EDA/SQL's  popularity  has 
declined  due  to  its  single  vendor  distribution  mode  and  the 
overshadowing  popularity  for  Microsoft's  ODBC  (Gallagher, 
1993)  . 
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c.  Distributed  Relational  Database  Architecture 

(DRDA) 

IBM's  native  mainframe  networking  protocol  is  the 
System  Network  Architecture  (SNA).  IBM's  System  Application 
Architecture  (SAA) ,  created  in  1987,  is  a  design  specification 
for  creating  applications  that  can  run  on  and  access  any  IBM 
computer,  regardless  of  the  type  of  platform  used  for 
application  development.  Along  with  SAA,  IBM's  attempt  to 
enter  the  client/server  market  is  the  Application  Program-to- 
Program  Communications  (APPC)  protocol,  based  on  SNA,  which 
runs  on  any  IBM  platform  and  allows  applications  running  on 
one  system  to  communicate  with  applications  on  other  systems. 
The  DRDA  protocol  is  part  of  IBM's  SAA,  and  describes  how 
RDBMSs  on  different  platforms  can  communicate  with  each  other 
in  a  client/server  mode.  DRDA  has  the  primary  purpose  of 
connecting  LAN-based  IBM  databases  to  mainframe-based  IBM 
databases  (DB2) .  Other  DBMS  vendors  also  have  licenses  to 
build  DRDA  drivers,  allowing  LAN-based  IBM  databases  to  access 
their  DBMS  as  well.  DRDA's  strengths  are  its  support  features 
for  managing  large  systems;  its  principal  weakness  is  lack  of 
implementation.  (Gallagher,  1993;  Watterson,  1993,  Salemi, 
1993) 

d.  ISO  Remote  Data  Access  (RDA) 

RDA  is  an  ISO  international  standard  for  a  common- 
protocol  approach  to  remote  data  access.  RDA  provides  a  very 
limited  generic  implementation,  using  dynamic  SQL,  ANSI/ISO 
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SQL  syntax,  and  the  Open  Systems  Interconnect  (OSI)  protocol 
stack.  Lack  of  support  for  the  more  common  Transport 
Communications  Protocol/Interconnection  Protocol  (TCP/IP) 
protocol  stack  currently  prevents  RDA's  growth  in  industry. 
(Watterson,  1993) 

e.  Distributed  Object  Integration  Tool  (DOIT) 

The  Distributed  Object  Integration  Tool  (DOIT)  is 
an  attempt  by  Object  Systems  to  define  an  integrated 
architecture,  based  on  distributed  object  computing,  that 
supports  distributed  data  access  without  using  APIs  or 
drivers.  DOIT  offers  a  single  platform  for  use  with  many 
diverse  types  of  applications,  providing  an  integrated 
comprehensive  approach,  and  as  such  deserves  mention.  The 
DOIT  product  results  from  two  requirements:  the  need  to 
integrate  data  from  heterogeneous  systems  in  real  time;  and 
the  need  to  be  able  to  define  data-access  routines  without 
using  programming  languages  or  APIs,  based  on  the  assumption 
that  industry  would  not  adopt  a  standard  API  for  distributed 
data  services.  DOIT  uses  high-level  graphical  tools  to  define 
and  access  data  sources,  which  are  defined  as  objects  through 
encapsulation. 

The  DOIT  architecture  contains  three  types  of 
objects  and  a  set  of  runtime  services.  The  objects  are:  Data 
objects.  Execution  objects,  and  Manager  objects.  Data  objects 
encapsulate  data  from  a  database,  application,  or  other 
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source.  These  are  the  only  objects  visible  to  the  user,  and 
can  be  directly  manipulated  by  the  user,  routed  to  other 
applications,  or  held  in  internal  storage. 

Execution  objects  are  the  internal  structures  that 
implement  DOIT  functionality.  The  five  types  of  Execution 
objects  are:  Source  (data  source),  Sink  (data  recipient). 
Filter  (business  rules) ,  Trigger  (events) ,  and  Notification 
(delivery  methods) .  DOIT  supports  point-to-point,  multicast, 
narrowcast,  and  broadcast  modes  of  communications  among 
obj  ects . 

Manager  objects  are  the  components  of  the  runtime 
environment.  The  four  Manager  objects  are:  Object  Integration 
Engine  (OIE) ,  Object  Router,  Persistent  Storage  Object,  and 
the  Object  Browser.  The  Object  Integration  Engine  is  the 
heart  of  DOIT,  and  provides  the  control  over  all  objects.  The 
Object  Router  provides  the  linkages  required  among  objects. 
The  Persistent  Storage  Object  provides  a  local  storage 
location.  The  Object  Browser  is  a  front-end  tool  for 
identifying  and  manipulating  objects  present  in  the 
environment  —  this  allows  the  user  to  view  the  data 
encapsulated  in  an  object. 

The  data  sources  are  encapsulated  by  a  Legacy 
Application  Wrapper  (LAW)  using  three  methods  of  integration: 
file-level  integration,  I/O-level  integration,  and  dynamic- 
data  integration.  File-level  integration  occurs  when  a  LAW 
encapsulates  an  application's  files.  I/O-level  integration 
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occurs  when  a  LAW  encapsulates  an  application's  I/O  interrupt. 
Dynamic-data  integration  occurs  when  a  LAW  encapsulates  a 
standard  application-integration  protocol,  such  as  Microsoft's 
Dynamic  Data  Exchange  (DDE)  or  Object  Linking  and  Embedding 
(OLE)  . 

The  DOIT  environment  can  easily  encompass  the 
SAG'S  CLI  specification  and  the  OMG's  CORBA  architecture. 
DOIT  can  rely  on  CORBA  as  a  standards-based  Object  Router,  and 
can  use  SAG's  CLI  API  as  a  LAW  dynamic  data  integration 
standard.  However,  neither  CORBA  nor  SAG's  CLI  provide  equal 
functionality  to  DOIT.  (Rymer,  1993) 
f.  Data  Switches 

A  Forrester  Research  Inc.  study  report  (1993) 
predicts  that  industry  pressure  will  force  ODBC  and  IDAPI  to 
merge  and  form  a  single  API  standard.  Even  then,  the  merged 
standard  does  not  provide  the  required  performance.  According 
to  Forrester,  what  is  needed  are  "data  switches".  Data 
switches  are  server  software,  created  by  database  vendors, 
that  control  broad  access  to  heterogeneous  databases.  Data 
switches,  packaged  as  RDBMS  extensions,  have  three  functions: 
translation  between  heterogeneous  DBMSs,  administration,  and 
provision  of  a  global  dictionary.  (Eastwood,  1993) 
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APPENDIX  F:  REQUIREMENTS  AND  aXTERNATIVES  ANALYSES  METHODS 

Systems  Analysis  and  Design  literature  contains  numerous 
discussions  of  the  different  methods  for  conducting 
requirements  analysis;  most  of  these  methods  generally  have 
several  points  in  common.  Federal  and  DoD  acquisition 
regulations  also  address  requirements  analysis,  and  provide 
specific  guidance  on  minimum  requirements.  This  appendix 
discusses  the  information  system  (IS)  requirements  and 
alternatives  analyses  guidelines  found  in  the  Federal 
Information  Resources  Management  Regulations  (FIRMR) (41  CFR 
201),  supported  by  the  discussions  in  a  supplemental  guide 
published  by  the  General  Services  Administration  (GSA) ,  A 
Guide  for  Requirements  Analysis  and  Analysis  of  Alternatives 
(GSA-IRMS,  1990)  .  The  FIRMR  identifies  niomerous  factors  to  be 
considered  during  any  IS  requirements  analysis;,  these  are 
briefly  outlined  in  the  first  section  of  this  appendix. 
Similarly,  the  FIRMR  includes  several  procedures  for  the 
conduct  of  the  analysis  of  alternatives;  these  are  briefly 
described  in  the  second  section  of  this  appendix. 

A.  REQUIREMENTS  ANALYSIS  FACTORS 

The  purpose  of  a  requirements  analysis  is  to  determine  and 
document  an  organizational  need  for  information  processing 
resources.  The  FIRMR  lists  ten  factors  as  the  minimum  issues 
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to  be  considered  during  an  IS  requirements  analysis  (41  CFR 
201-20.103.1-103.10).  These  include: 

1 .  Information  Needs  or  Requirements 

The  information  needs  factor  addresses  a  requirement 
for  an  organization  to  identify  its  information  needs,  taking 
into  account  all  the  possible  internal  and  external 
considerations.  Examples  of  these  considerations  include  the 
organization's  function  or  mission,  available  information 
sources,  external  information  demands,  record  storage 
requirements,  and  information  format. 

The  GSA  guide  provides  a  more  detailed  listing  of 
factors  to  consider  when  determining  information  requirements, 
which  expands  on  the  FIRMR's  list.  The  GSA  guide  also 
provides  recommendations  that  go  beyond  the  minimum 
requirements  in  the  FIRMR.  One  such  recommendation  is  that 
an  organization  should  describe  and  define  the  current  system 
in  order  to  establish  a  baseline  for  identifying  the  future 
requirements.  As  part  of  this  analysis  of  the  current  system, 
GSA  recommends  that  the  current  system  undergo  a  performance 
evaluation. 

2 .  System  Life 

An  organization  establishes  an  expected  information 
system  life,  from  the  point  of  view  of  the  organization's  use 
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of  the  resources  (organizational  lifetime) ,  and  from  the  point 
of  view  of  potential  reuse  by  another  organization  later 
(total  lifetime) . 

3 .  Description  of  Requirements 

The  description  of  the  requirements  is  obviously  the 
key  element  in  requirements  analysis.  This  description 
generally  has  two  parts:  the  basis  for  the  requirements,  in 
terms  of  mission  needs;  and  the  actual  requirements,  in  terms 
of  functionality  and  performance  required.  As  part  of  the 
requirements  definition  process,  an  organization  reviews  all 
International,  Federal,  Department  of  Defense  (DoD) ,  and  other 
Agency  standards  for  applicability  to  each  requirement. 

The  FIRMR  also  directs  organizations  to  prevent  less 
than  full  and  open  competition  during  the  contracting  phase 
due  to  unnecessarily  restrictive  requirements. 

4 .  Conpatibility-Limited  Requirements 

The  FIRMR  requires  a  formal  justification  for  any 
requirements  that  restrict  the  hardware  or  software  to 
components  that  must  be  compatible  with  existing  Federal 
information  processing  (FIR)  resources.  The  justification 
basis  is  an  economic  feasibility  analysis  of  technical  and 
operational  requirements,  or  the  risk  and  impact  of  a  hardware 
or  software  conversion  failure. 
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5.  Justification  for  Specific  Make  and  Model 


The  FIRMR  also  requires  a  formal  justification  for  any 
requirements  that  list  a  specific  "make  and  model"  hardware  or 
software  component. 

6 .  Security  Requirements 

The  security  requirements  meet  the  security  and 
privacy  needs  of  the  proposed  system;  these  requirements 
include  a  discussion  of  the  potential  threats  and  hazards,  the 
methods  for  protection  against  these  threats,  and  additional 
physical  and  environmental  safeguards. 

7.  Accessibility  Requirements  for  Individuals  with 

Disabilities 

Accessibility  requirements  provide  disabled  personnel 
with  equivalent  access  to  electronic  office  equipment  and 
telecommunication  devices,  in  accordance  with  other  Federal 
regulations . 

8.  Space  and  Environmental  Requirements 

The  requirements  for  physical  space  and  environmental 
support,  such  as  heating  and  cooling,  must  be  addressed  within 
the  requirements  analysis. 

9 .  Workload  and  Related  Requirements 

The  description  of  predicted  workload  requirements  is 
frequently  one  of  the  hardest  factors  to  analyze,  since  it 
includes  a  projection  of  the  processing,  storage,  data  entry, 
communications,  and  support  services  requirements  over  the 
system's  life.  The  discussion  must  also  include  expandability 
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requirements,  contingency  requirements,  and  a  performance 
evaluation  of  the  currently  installed  information  processing 
resources . 

10.  Records  Management  Requirements 

All  the  issues  surrounding  records  management  for 
Federal  agencies,  such  as  the  use  of  the  Standard  and  Optional 
Forms  Management  Program,  must  be  included  in  the  requirements 
analysis  to  ensure  continued  interoperability  with  other 
programs,  and  prevent  duplication  of  effort. 

B.  PROCEDURES  FOR  ANALYSIS  OF  ALTERNATIVES 

The  FIKMR  directs  organizations  to  consider  several 
factors  when  attempting  to  identify  and  analyze  the  available 
alternatives  that  would  meet  the  resource  requirements .  The 
basis  for  any  alternatives  analysis  is  the  statement  of 
requirements  that  results  from  the  requirements  analysis 
phase.  Alternatives  are  compared  and  evaluated  against  this 
statement  of  requirements  to  determine  the  most  advantageous 
alternative  that  meets  the  requirements. 

1.  Consideration  of  Alternatives 

The  guidance  requires  organizations  to  first  conduct 
some  form  of  market  research  to  determine  if  the  required 
technology  is  available,  and  identify  potential  candidates  as 
feasible  alternatives.  The  market  analysis  includes  many 


237 


sources:  vendor  and  industry  contacts,  trade  shows,  peer 

groups,  published  materials,  and  even  requests  for  information 
(RFI) . 

Next,  an  organization  must  look  at  GSA's  mandatory 
programs  —  mandatory-for-use  and  mandatory-for-consideration 
--  to  determine  if  any  of  these  can  meet  the  requirements. 
The  GSA  mandatory-for-use  programs  include:  the  FTS  2000 
network  to  satisfy  long  distance  telecommunications 
requirements,  consolidated  local  telecommunications  services. 
Purchase  of  Telephones  and  Services  (POTS)  program,  the 
National  Security  and  Emergency  Preparedness  (NSEP)  program, 
and  the  Financial  Management  Systems  Software  (FMSS)  Multiple 
Awards  Schedule  (MAS)  Contracts  program.  Non-use  of  these 
mandatory-for-use  programs  requires  a  waiver  from  GSA. 

The  GSA  mandatory-for-consideration  programs  include: 
the  Federal  Software  Exchange  Program  (FSEP),  the  Excess  FIP 
Equipment  program,  the  Federal  Secure  Telephone  Service 
(FSTS),  and  Information  Systems  Security  (INFOSEC)  services 
and  programs,  including  Communications  Security  (COMSEC) 
systems  and  services. 

Other  alternatives  to  be  considered  include  reusing 
Federal  Information  Processing  (FIP)  resources  discarded  by 
other  organizations,  sharing  existing  FIP  resources, 
contracting  for  FIP  resources,  and  using  GSA's  non-mandatory 
programs  (single  and  multiple  award  schedule  contracts)  and 
assistance . 
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2.  Cost  for  Each  Alternative 


The  projected  acquisition  cost  determines  which  cost 
analysis  method  must  be  used.  If  the  expected  cost  is  less 
than  $50,000,  only  a  simple  cost/benefit  analysis  is  required 
for  each  alternative  under  consideration.  However,  if  the 
anticipated  cost  is  greater  than  $50,000,  the  net  present 
value  of  the  total  estimated  cost  of  each  alternative  must  be 
calculated  and  used  during  the  analysis.  The  total  estimated 
cost  consists  of  the  system  life  cost  and  any  other  costs  that 
would  be  associated  with  that  alternative,  whether  incurred 
before  or  after  the  system  life  timeframe.  The  total 
estimated  cost  includes  costs  attributed  to  the  project  in 
several  related  areas,  including:  personnel  salaries  and 
training  costs,  office  supply  costs,  utility  costs, 
maintenance  costs,  and  site  preparation  costs. 

The  GSA  guide  includes  a  discussion  of  several  non¬ 
cost  functional  and  risk  factors  which  should  be  considered  as 
well.  The  functional  factors  include  availability, 
reliability,  maintainability,  expandability,  flexibility, 
security,  privacy,  personnel  impacts,  user  acceptance,  and 
accountability  (audit) .  The  risk  factors  are  financial  risks, 
technical  risks,  and  schedule  risks. 

3 .  Conversion  Analysis 

Selection  of  a  specific  alternative  often  requires 
that  other  FIP  resources  may  have  to  be  converted  (i.e.,  from 
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one  programming  language  to  another),  replaced  (i.e.,  from  one 
hardware  platform  to  another) ,  or  discarded.  Therefore,  a 
conversion  analysis  looks  at  the  costs,  risks,  and  size  of  any 
conversion  required.  The  FIRMR  provides  a  listing  of  expenses 
which  should  not  be  included  as  conversion  costs;  an  example 
of  a  disallowed  expense  is  the  costs  associated  with  purging 
duplicate  or  obsolete  FIP  software,  data  bases  and  files. 

4 .  Obsolescence  Analysis 

This  analysis  ensures  that  an  organization  has 
developed  a  strategy  to  prevent  FIP  resources  from  becoming 
obsolete  before  the  end  of  projected  system  life. 

5.  Capability  and  Performance  Validation 

The  FIRMR  requires  that  an  organization  conduct  a 
capability  validation  and  a  performance  validation  of  each 
alternative  as  part  of  the  process  of  evaluation.  Each 
organization  determines  the  actual  techniques  to  be  used  in 
the  validation  process. 

Capability  validation  is  the  technical  verification 
that  the  proposed  alternative  meets  the  functional 
requirements.  The  capability  validation  process  does  not 
evaluate  or  measure  any  performance  characteristics;  that  is 
left  for  the  performance  validation.  Techniques  used  for 
capability  validation  range  from  contacting  other  users  of  the 
proposed  resource  to  full  vendor  or  organizational  operational 
capability  demonstrations  of  the  system's  functionality. 
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Performance  validation  is  the  technical  verification 


that  the  proposed  alternative  can  handle  the  specified 
workload  within  the  specified  performance  time  constraints. 
The  tested  workload  includes  both  present  and  projected 
workload  volumes.  Examples  of  performance  validation 
techniques  are:  timed  execution  of  existing  applications  and 
data,  simulation  modeling,  stress  testing,  benchmarking,  and 
acceptance  testing. 
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